[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 25 Jul 2019 16:03:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Removing glibc from the musl .2 ABI
On Thu, Jul 25, 2019 at 09:42:23AM -0700, James Y Knight wrote:
> On Wed, Jul 24, 2019 at 2:29 PM Rich Felker <dalias@...c.org> wrote:
>
> > On Wed, Jul 24, 2019 at 09:33:05AM -0700, James Y Knight wrote:
> > > One thing I've not seen mentioned yet: if this is done, then anyone
> > > (whether intentionally or inadvertently) who links any glibc-compiled .o
> > or
> > > ..a files into a musl binary/shared-lib will be broken.
> >
> > If it referenced glibc symbols that have been moved out of musl, it
> > would just fail to link (at ld time or ldso time, depending on program
> > binary/shared lib). The only way it would be silently broken is with
> > symbols where glibc and musl share the same symbol name but with
> > different ABI (like regexec on 64-bit, which is already possible now,
> > or the non-64bit-off_t functions on 32-bit archs, or lots of stuff on
> > mips and powerpc where there's minimal or no ABI-compat).
> >
> > For the time64 stuff, my thought is to try to use redirected-symbol
> > names that don't match whatever names glibc will be using, so that
> > there's no risk of the link accidentally succeeding. I think it makes
> > sense in general to try to have ABI match when we add symbols that
> > will also exist in glibc, on the archs that have ABI-compat.
> >
> > > Up until now, with musl's mostly-glibc-compatible ABI, you could link the
> > > two object files together, and generally expect it to work. When
> > > compatibility is instead done with magic in the dynamic loader, that
> > > obviously can only ever work with a shared-object boundary.
> > >
> > > I don't know if anyone actually uses musl in a context where this is
> > likely
> > > to be a problem, but it at least seems worth discussing (and loudly
> > > documenting as a warning to users not to do this if implemented).
> >
> > My thought, for the things where it matters, is that it's an
> > improvement to fail. If you really want it to work (e.g. if you have a
> > binary-only static library you need to use), you can probably use
> > objcopy or similar to remap the symbols to shims.
> >
> > Does my above analysis sound reasonable to you?
>
> I had understood from your previous emails that musl would start dropping
> glibc-abi-compatibility (potentially in general, not just for the
> 64-bit-time transition) of existing "undecorated" functions, and then
> restore compatibility only in a shadowed version of that same function name
> in libgcompat.so.
Unless I misunderstand what you're saying, that's impossible without
also dropping musl-ABI compatibility. So no, it wouldn't happen.
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.
