[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190701153108.GR1506@brightrain.aerifal.cx>
Date: Mon, 1 Jul 2019 11:31:08 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On Mon, Jul 01, 2019 at 04:42:29PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 28, 2019 at 5:07 PM Rich Felker <dalias@...c.org> wrote:
> >
> > 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.
>
> Distros would probably need a varying amount of time to transition,
> right? Would you plan to support both time32 and time64 for a
> transition period, or would a distro that is not yet confident in rebuilding
> everything with time64 be stuck on the last time32 musl release
> before they do?
>
> I suppose the header files could be changed in a musl-1.2 release
> if the times line up, while musl-1.1.x can still get bugfixes?
".2" ABI doesn't mean "musl 1.2". It means ld-musl-*.so.2". If taking
this path, the plan was always to support both permanently (modulo
dropping .1 after 2038 ;) -- they'd just be different ABI targets.
> > 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.
>
> Sound great to me. I don't think it would be hard to make it
> conditional on top of that (just have an #ifdef __USE_TIME_BITS64
> around each symbol redirect in the headers), but I also prefer the idea
> that this is not something an individual compilation unit gets
> to decide.
Right. Unless we took it further and completely removed the old
symbols, preventing any new linking and making them only work via
hacks at the dynamic linker level, you absolutely could still link to
the old symbols just by using headers from an old version of musl, or
hacking the headers. But I'd rather not treat this as a supported
option. Due to the additional, hidden ABI-surface between apps and
third party libs, or between pairs of third-party libs, there's enough
risk of getting this wrong even with a single-direction, one-time
change. Having folks continue to compile individual apps and libs
inconsistently would make it even worse, like what happened with glibc
_FILE_OFFSET_BITS.
> > 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.
>
> Yes, this is also one of the things we eventually plan to do in Linaro,
> but have not actually started.
Would it be possible to prioritize starting this? It would be a big
help to deciding what direction we should take in musl and make this
move forward a lot quicker, I think. I was thinking we'd have to do it
ourselves or find someone else to convince to do it, but if Linaro
already plans to do this anyway, we could perhaps accelerate things
with no overall increase in effort to be spent.
> > 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.
>
> For those distros that build everything from source and generally
> don't update packages independently, another idea would
> be to have a way to leave out all the time32 symbols. This would
> immediately guarantee that they are not mixed.
Well if you just have the new headers, there's not really any way they
could get mixed except by failing to include the headers and declaring
the symbols yourself -- but then, for almost all cases, you'd be
missing the types needed to declare them, so it'd have to be something
like "long time(long *);" in the source, which is just horribly
broken. So I'm not sure there are any real-world cases where
removing/poisoning the old symbols would help.
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.
