[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190628150659.GD1506@brightrain.aerifal.cx>
Date: Fri, 28 Jun 2019 11:06:59 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Revisiting 64-bit time_t
I've been thinking on and off a lot more about the time_t problem on
32-bit archs. My original idea for fixing this has always been to
introduce the ".2 ABI", fixing a lot of poorly chosen struct layouts,
etc. at the same time we make time_t 64-bit, but of course requiring
users/distros to make an active choice to switch over ABI at some
point, and not getting any benefit until then.
The idea has been that users (like embedded) who don't care
much/at-all about an ecosystem of ABI-compatible binaries, but build
everything from source with buildroot or yocto or whatever, would
switch right away so that their devices don't become Y2038 time bombs,
and desktop/server distros that receive constant updates could make
the transition at their leisure.
However Y2038 is not all that far off, desktop/server distros really
have rather little interest left in 32-bit archs (especially not
coordinating a costly ABI swap just for them), and some of the
extensibility improvements we'd get from a ".2 ABI" would be just as
desirable or more desirable on 64-bit archs, which don't even have the
time_t motivation to do it now.
So I'm thinking more and more about doing a different fix. In a way
it's like how glibc did 64-bit off_t, and how they're doing 64-bit
time_t, except it wouldn't be switchable and wouldn't default to the
old behavior; once we pull the lever, everything would be built with
64-bit time_t. This would work via symbol redirction in the headers
for the affected functions (probably via a bits header for the 32-bit
archs), which is valid because, by virtue of using time_t or a derived
type, the standard requires that you include the headers to get the
declaration rather than declaring the function yourself.
Doing it this way does not break application-to-libc ABI, because the
old symbols still exist; they're just not used for linking new
programs. It does however impact ABI between libraries outside libc if
they use time_t or any of the derived types (timespec, stat, ...) in
their public (not internal, only public) APIs. How big that impact
would be is an open question; it might mean this approach would
require some coordinated updating of affected libraries and
applications using them in sync to prevent breakage.
Aside from community feedback, what's needed to make this possible, if
it's going to happen, is some good analysis of the scope of breakage.
Such analysis would also benefit glibc -- it would help determine how
safe their _TIME_BITS=64 option will be and whether it can be turned
on safely by default in the presence of old libraries built without
it. I've already discussed this casually with a few people and it
looks like the right starting point would be getting a Debian system
(Debian because their repo is utterly huge) with ALL library packages
installed and grepping /usr/include for all headers that involve
time_t or any of the derived types. Then, manual analysis would need
to be done to determine whether the usage actually has an impact.
If there are a significant number of affected libraries and we want to
go forward with something like this anyway, there should probably be
an optional patch distros can use to make ldso refuse to load certain
tagged .so files into a process where any of the 64-bit time symbols
have been referenced. This would ensure transitioning users get an
error message rather than silent misexecution.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
