This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval


On Fri, Jan 17, 2020 at 2:19 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 16 Jan 2020, Alistair Francis wrote:
>
> > > We want to end up at a point where, on systems where time_t is currently
> > > 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
> > > That means that all time-related functions, including getitimer and
> > > setitimer, will, on such systems, need to have two implementations in
> > > glibc, one using 64-bit times and one using 32-bit times.
> >
> > I'm still confused. If we build with -D_TIME_BITS=64 does that then
> > mean that __TIMESIZE == 64 ?
>
> No.  The semantics of __TIMESIZE are defined in the comment on
> bits/timesize.h.  It refers to the *default ABI*, not to any different ABI
> resulting from a setting of _TIME_BITS.  -D_TIME_BITS=64 will result in
> 64-bit time_t, but it will not change __TIMESIZE.
>
> > > The implementation structure generally being used is that the main
> > > implementation has an interface using 64-bit times (even if it ends up
> > > using syscalls with 32-bit times) and the one using 32-bit times is a thin
> >
> > Isn't that what is happening here when __TIMESIZE == 64 ?
>
> If __TIMESIZE == 64, the thin wrapper does not exist, because there's a
> "#if __TIMESIZE != 64" conditional around it (see e.g.
> sysdeps/unix/sysv/linux/clock_settime.c for the desired structure).
>
> > > wrapper around it (if time_t is already 64-bit, the second implementation
> > > does not exist and some macros ensure the first implementation keeps its
> > > existing name).  Once all functions have been moved to that structure, we
> > > can set things up so that all those 64-bit functions are exported from
> > > glibc and add _TIME_BITS support in the headers.
> >
> > Ah, do you mean that glibc should expose a 64-bit time_t version if
> > __TIMESIZE == 32? So even __TIMESIZE == 32 systems can call a 64-bit
> > time_t version (even if the syscall ends up being 32-bit).
>
> Eventually glibc should expose all those 64-bit time_t versions.

In this case won't that just happen automatically when _TIME_BITS is
64 (64-bit time_t)?

>
> Right now, when __TIMESIZE == 32 those versions should be defined, and
> called by the thin wrappers for 32-bit time_t, but not exported at public
> symbol version (until all of them exist and all the header changes are
> ready).

In this case though there is no 64-bit time_t syscall (we only have
32-bit even with 64-bit time_t) so why expose a 64-bit version?

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]