This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
On Thu, Jul 18, 2019 at 7:36 PM Alistair Francis <alistair23@gmail.com> wrote:
> On Thu, Jul 18, 2019 at 2:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Jul 18, 2019 at 12:43 AM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > Yes, if I use the generic ones for RV32 I see build failures as some
> > > of the structs don't align (I can't remember which ones now). So this
> > > is required to build.
> >
> > I think what it really means is that you have to fix up those build
> > failures by changing the broken code. Using mismatched types to
> > address build failures just replaces them with runtime failures but
> > does not result in a working systems.
>
> Good point, I have fixed the other issue. This is what I have now,
> which matches the generic typesizes:
Ok, just to confirm, I'm looking at the difference between your
version and sysdeps/unix/sysv/linux/generic/bits/typesizes.h:
--- sysdeps/unix/sysv/linux/generic/bits/typesizes.h 2019-06-25
13:02:42.301241279 +0200
+++ typesize.h +0200
...
#define __DEV_T_TYPE __UQUAD_TYPE
#define __UID_T_TYPE __U32_TYPE
#define __GID_T_TYPE __U32_TYPE
-#define __INO_T_TYPE __ULONGWORD_TYPE
+#define __INO_T_TYPE __UQUAD_TYPE
#define __INO64_T_TYPE __UQUAD_TYPE
#define __MODE_T_TYPE __U32_TYPE
#define __NLINK_T_TYPE __U32_TYPE
-#define __OFF_T_TYPE __SLONGWORD_TYPE
+#define __OFF_T_TYPE __SQUAD_TYPE
#define __OFF64_T_TYPE __SQUAD_TYPE
#define __PID_T_TYPE __S32_TYPE
-#define __RLIM_T_TYPE __ULONGWORD_TYPE
+#define __RLIM_T_TYPE __UQUAD_TYPE
#define __RLIM64_T_TYPE __UQUAD_TYPE
-#define __BLKCNT_T_TYPE __SLONGWORD_TYPE
+#define __BLKCNT_T_TYPE __SQUAD_TYPE
#define __BLKCNT64_T_TYPE __SQUAD_TYPE
-#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE
+#define __FSBLKCNT_T_TYPE __UQUAD_TYPE
#define __FSBLKCNT64_T_TYPE __UQUAD_TYPE
-#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE
+#define __FSFILCNT_T_TYPE __UQUAD_TYPE
#define __FSFILCNT64_T_TYPE __UQUAD_TYPE
#define __FSWORD_T_TYPE __SWORD_TYPE
#define __ID_T_TYPE __U32_TYPE
#define __CLOCK_T_TYPE __SLONGWORD_TYPE
-#define __TIME_T_TYPE __SLONGWORD_TYPE
+#define __TIME_T_TYPE __SQUAD_TYPE
#define __USECONDS_T_TYPE __U32_TYPE
-#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE
+#define __SUSECONDS_T_TYPE __SQUAD_TYPE
#define __DADDR_T_TYPE __S32_TYPE
#define __KEY_T_TYPE __S32_TYPE
#define __CLOCKID_T_TYPE __S32_TYPE
...
This all seems reasonable, but it's worth spelling out the decisions
that went into it:
- All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t, ...) are
changed to match the 64-bit replacements. I would have preferred to
completely leave them out and always define __USE_FILE_OFFSET64,
but I don't think anyone else liked that idea, so that's ok.
- __time_t is defined to 64 bit, but no __time64_t is added. This makes sense
as we don't have the time64 support for other 32-bit architectures yet, and
it will be easy to change when that happens.
- __suseconds_t is 64-bit. This matches what we use the kerne ABI for the
few drivers that are relying on 'struct timeval' input arguments in
ioctl, as well as
the adjtimex system call. It means that timeval has to be defined without the
padding, unlike timespec, which needs padding.
Arnd