On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski firstname.lastname@example.org wrote:
On Fri, Mar 13, 2020 at 9:22 PM Rich Felker email@example.com 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.