Re: Trying Debian/armhf rebootstrap with time64
- To: Lukasz Majewski <lukma@denx.de>
- Cc: Rich Felker <dalias@libc.org>, y2038 Mailman List <y2038@lists.linaro.org>, GNU C Library <libc-alpha@sourceware.org>, debian-arm@lists.debian.org, tcwg@linaro.org, Helmut Grohne <helmutg@debian.org>, Wookey <wookey@wookware.org>, Adhemerval Zanella <adhemerval.zanella@linaro.org>, Steve McIntyre <steve@einval.com>, Jan Kiszka <jan.kiszka@web.de>, Riku Voipio <riku.voipio@iki.fi>
- Subject: Re: Trying Debian/armhf rebootstrap with time64
- From: Arnd Bergmann <arnd@arndb.de>
- Date: Wed, 18 Mar 2020 15:33:26 +0100
- Message-id: <[🔎] CAK8P3a1pgZmS7wZbBATtraNn3pXN-MvTxerm8vhOcUehAi4rrA@mail.gmail.com>
- In-reply-to: <[🔎] 20200316231248.2ef16f97@jawa>
- References: <[🔎] CAK8P3a0EtmgDRbDzBhOOZk_kyWmCm1aqvSxwUeY0R7tbCSxaKg@mail.gmail.com> <20200313202234.GA3980@brightrain.aerifal.cx> <[🔎] CAK8P3a0eDr5d1s9mqfs7HXXeCMAT7=dxftbM91ny0f6fAd3Zjg@mail.gmail.com> <[🔎] 20200316231248.2ef16f97@jawa>
On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dalias@libc.org> wrote:
> > > > - Removing the time32 symbols from the glibc shared object did
> > > > not work as they are still used (a lot) internally, and by the
> > > > testsuite.
> > >
> > > That they're used internally sounds like a major problem; anywhere
> > > they're being used internally potentially has hidden Y2038 bugs.
> > > This is also why I'm concerned about glibc's approach of not
> > > building itself with _TIME_BITS=64, and just undefining it or doing
> > > something else in the wrapper files for the legacy time32 symbols.
> >
> > I thought this was the long-term plan. Working on the ABI first and
> > then changing the implementation may help speed up the timeline
> > before distro-level work can start, but OTOH removing all the 32-bit
> > codepaths from the implementation first makes it more likely to find
> > all relevant bits.
>
> If I understood the question correctly - the problem is with having
> glibc ABI consistent. This requires having 64 bit types for relevant
> functions. For example the __clock_settime64 accepts struct
> __timespec64 parameter which:
>
> - Is aliased to "normal" struct timespec on machines with
> __WORDSIZE==64 (x32 is a special case)
>
> - The struct __timespec64 is used on 32 bit machines
>
> As a result the glibc is ready to handle 64 bit time always (with
> clock_settime on __WORDSIZE==64 or clock_settime64 otherwise), as
> exported struct timespec fields size vary depending on the machine for
> which glibc is built.
I think we all understand the need to duplicate each interface that
passes a data type derived from time_t, and how the aliasing works,
The point above is purely for the internal implementation. The approach
that I have picked for the kernel and Rich did for musl was that
internal code never sees the old __time_t definition for any data
structure or function call, those are only used to define the wrappers
for 32-bit architectures that provide the legacy interfaces.
Arnd
Reply to: