[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190629163501.GK1506@brightrain.aerifal.cx>
Date: Sat, 29 Jun 2019 12:35:01 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On Fri, Jun 28, 2019 at 11:06:59AM -0400, Rich Felker wrote:
> [...]
> 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.
A couple observations:
1. dlsym is problematic.
You can't have a correct implementation where dlsym("time") returns
the old (now-signature-mismatched) time symbol rather than the
redirected one.
I think this just necessitates having affected archs also redirect the
dlsym symbol, to call a patch-up wrapper. Moderately ugly, but not a
show-stopper.
2. The glibc ABI-compat __statx stuff.
I'm not sure if glibc is using these for its time64 versions of the
interfaces, or if it finally abandoned that broken framework (that
beaks both dlsym and function pointer equality). If they're still
using it and we want to maintain support for ABI-compat, we need to
update these to handle the time64 versions too.
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.
