This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alistair Francis <alistair23 at gmail dot com>
- Cc: Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Arnd Bergmann <arnd at arndb dot de>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Palmer Dabbelt <palmerdabbelt at google dot com>, "Maciej W. Rozycki" <macro at wdc dot com>, Zong Li <zongbox at gmail dot com>
- Date: Thu, 16 Jan 2020 16:19:32 +0000
- Subject: Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
- Ironport-sdr: TWQ+ojv8KAaTd4QJIGNu+XOBebGr0pgx6EspnxbLu7VolvTHnxCKiGc58sXSCQBSrjMeAYkhWt HXFA4NEPS7BLJzJApLC2GVX67golSaQweo4PoOzFbl2HQtPmcin4VwPamVecSwO9YeksFkKRDr 5YVjLclampM5sx6vGPDLTUclB99y+cTN74VtPV+Dnhd0VM98jbmFNuBLoOgthrpJv3NhNPMdyl yc2rz+4ASh/k2MwOhXvL6tl0pMzGFF23pzLLIDjAg0RnMCoQGAxYUsq/ttMZj5cPiB+OtToCHe jgs=
- Ironport-sdr: gmUTmo8ZtNeVeJ/ZhPK8X0G/SAssQn1MG5hehGAJsWp0KbzmahHMfqRW7fNNwBNPfk2nju7Hkh 2U2an2M7lOk+iemep5VXYLDG+/XXNVpu8AeABP03lexMw+aheubW6POSS2ZdR1enKLA4uSNv+X bsI79Jg89PlvOTTErp5Umzfty7jrFm59bd9CiKxwK2bEMGEsqf8H4IYXfcUiXExrf6kQ+jlQoN I0mk6f0IPS+voF1miDkB8/N9pwLwp4KYcodPMHJ7vXF0suUY1puyO/VY+mCO/vF9WM2KISiQ4o w2s=
- References: <cover.1578824547.git.alistair.francis@wdc.com> <6fce89fec812352770884a62c6fa158890480e2a.1578824547.git.alistair.francis@wdc.com> <20200114115848.396c6eaf@jawa> <CAKmqyKN1noTcCVMSCfS_wNOCGOtssaB9bDJ16JafMzUzvnmpcA@mail.gmail.com> <alpine.DEB.2.21.2001160117490.11220@digraph.polyomino.org.uk> <CAKmqyKO4dcnZnu0kryZFSJxp=t8BwS1Jkupf5Na6PeD4DM2j2g@mail.gmail.com>
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.
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).
--
Joseph S. Myers
joseph@codesourcery.com