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.