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