[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jul 2013 13:18:06 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Preparing to release 0.9.12
On Thu, Jul 25, 2013 at 07:59:55PM +0300, Timo Teras wrote:
> > I apologize that the lack of C++ ABI stability was not warned about
> > prominently in previous releases. If you (or anyone else) have
> > deployed packages that you think will break, I can look into adding a
> > layer in the dynamic linker that would, when a C++ symbol lookup
> > fails, try substituting differently-mangled symbols which differ from
> > the desired one only in the nominal identity of the type but not in
> > its size or representation. This would not be too hard, but unless
> > it's needed, it's probably a bad idea.
>
> Full agree. And no, no need for the symbol name "re"-mangling hack.
> Still working on my initial build.
Great. This is why I've been rushing to get these changes done sooner
rather than later -- I want users of musl to be starting off with
something that's stable.
> > Finally, please note that any breakage from the C++ ABI changes will
> > be unresolved symbol errors at startup, not application misbehavior.
>
> Yes. I figured this. And it would be namely on the C++ libraries. Not
> on musl itself, as the musl symbols never changed. It's just C++
> compiler's perception of the type names.
Exactly.
> > > Relatedly, commit f389c4984a (make the dynamic linker find its path
> > > file relative to its own location) introduced the armeb, armhf
> > > variants. Fundamentally, these are distribution specific names. I
> > > believe debian has/had armeb (big-endian OABI; being retired), arm
> > > (little-endian OABI; dead port), armel (little-endian EABI), and now
> > > armhf (little-endian EABI with hard-float). But these are by no
> > > means standard. While it is good that LDSO_ARCH gets good default
> > > with this distinguished. It should be allowed to be overridden by
> > > distributions.
> [...]
> Well, now that you've added most needed subarches, I'm probably ok. I
> was just anticipating that if toolchain gets new feature affecting ABI,
> you need to track those all. But if you aim universal compatibility
> then this needs to be done. I guess there will not be insane amount of
> subarches, but you never know about future.
I should add some documentation on this on the wiki. Defining what is
part of "the ABI" is tricky. For example, you could say code built for
armv5 is a different ABI from code built for armv4, since it's using
instructions that aren't available on armv4. However, the key reason I
don't consider those "different ABIs" is that, as long as the cpu
you're running on supports all the instructions used in the main
program and all libraries, you can use a mix of armv4 and armv5 built
modules with no restrictions.
The ABI variants musl is dealing with in the subarch naming system are
basically limited to:
- Archs that have both little and big endian variants, which really
should be thought of as completely different archs, but since they
share all the code, it's more practical to treat them as subarchs.
- Variations in calling convention, for example, passing floating
point arguments in floating point registers versus general purpose
registers or on the stack. For example, on arm, -mfloat-abi=soft and
-mfloat-abi=softfp are both the same subarch, because the calling
convention is the same, and code built with the two modes can be
linked together. But -mfloat-abi=hard is a separate subarch because
you cannot link it with code built with the other options (unless
none of the interfaces between the modules use float).
Basically, configurations A and B are different archs or subarchs if
you can't link code built with configuration A to code built with
configuration B.
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.
