Hi Arnd, > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dalias@libc.org> wrote: > > > > On Wed, 11 Mar 2020 13:52:00 +01000, Arnd Bergmann wrote: > > > As discussed before, I tried using the rebootstrap tool [1] to > > > see what problems come up once the entire distro gets rebuilt. > > > Based on Lukasz' recommendation, I tried the 'y2038_edge' branch > > > with his experimental glibc patches [2], using commit > > > c2de7ee9461 dated 2020-02-17. > > > > > > Here is a rough summary of what I tried, what worked, and what > > > problems I ran into: > > > > > > [...] > > > > > > * Actually building a time64 version of glibc turned out to be > > > harder, including some issues discussed on the libc mailing > > > list[5]: > > > > > > - Always setting -D_TIME_BITS=64 in the global compiler flags > > > for the distro breaks both the native 64-bit (x86_64) build and > > > the 32-bit build, as glibc itself expects to be built without > > > this. > > > > This seems like a small issue, but glibc should probably either > > remove it from CFLAGS in the build system or at least catch it at > > configure time and error out, so that it's not confusing when it > > breaks. > > Right, that would make sense. For the test suite though, I guess > it would actually need to run each test case that references > time_t both ways. > > > > - 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. > > > > - The nptl and sunrpc portions have numerous interfaces with > > > 'timeval' or 'timespec' arguments that each cause an ABI > > > break. > > > > nptl is essential but I think sunrpc is pure legacy ABI and not > > intended to be linkable in the future. > > That would be helpful, but what does it mean for distro packages > that link against it today? > codesearch.debian.org e.g. finds nfs-utls, nis, libtirpc, ntirpc > and nfswatch including <rpc/*.h>. Can these just use a > replacement that is built with 64-bit time_t then? > > Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Attachment:
pgpCmWquqQ7er.pgp
Description: OpenPGP digital signature