On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski <lu...@denx.de> wrote:
> > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dal...@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
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
