[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200729011606.GR6949@brightrain.aerifal.cx>
Date: Tue, 28 Jul 2020 21:16:07 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: musl@...ts.openwall.com
Subject: Re: friendly errors for ABI mismatch
On Tue, Jul 28, 2020 at 10:40:35AM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > Symbol versioning, if used, changes this somewhat by binding to a
> > particular version string (which by convention usually contains a
> > library name too) *if* the library used to resolve it at runtime has
> > versioning, but for very good reasons we have not used and do not want
> > to use symbol versioning. (In short, like here it's an "approximate
> > solution" for most things people want to use it for, doesn't actually
> > achieve those things precisely, messes other things up in the process,
> > and has really really bad tooling support.)
>
> I think you should look at this from a different angle. You could use
> it just to produce an error message in case there is an ABI change,
> but not for backwards compatibility with old binaries or enabling
> otherwise ABI-incompatible changes without rebuilding the world.
The only ABI change here is in the ABI defined between libc consumers
using the time_t-derived libc types. From the standpoint of musl's ABI
surface, the change here was similar to any other instance of adding
new interfaces for new functionality except that the new symbols get
used implicitly via redirection rather than only when directly
referenced by the application.
> With this approach, all symbols would have a single, default version.
> New releases do not add new symbol version strings in general, except
> when there is something like time64_t, in which the default (and only
> version) for those symbols changes. Over time, you will end up with a
> few symbol versions, but at a much slower pace than what glibc does.
I didn't want to get into a detailed discussion of how symbol
versioning is broken, but it is broken, and using it in place of
symbol redirection for time64 would not have meet the needs here. In
particular, without hacking on nonstandard semantics for version
resolution, the following would not work:
- Mixing old object files (static libraries) in code built with new
musl and time64, or vice versa.
- Supporting call-intercepting interposition libraries like fakeroot
in a way that's safe for both time32 and time64 binaries.
I suspect there are others that I'm not recalling right off. At least
dlsym would have needed to be handled differently but I suspect it
would still be possible to make it work.
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.
