Hi folks, We're currently carrying patches in glibc in Debian (and Ubuntu) that I wrote which are used to work out whether an ELF binary is hard-float or soft-float. We're using these to allow us to do the right thing on a multi-arch system, which is to pick a consistent set of binaries (programs and libraries) at runtime; if you try to mix binaries using different ABIs, you're prone to all kinds of weird and wonderful results but generally badness occurs.
Upstream glibc have generally not been welcoming of these patches, and I understand this; the approach taken (reading ARM-specific build attributes) is far from clean and doesn't fit well in the design of ld.so in particular. So, I've been looking into alternative methods for achieving the goal of identifying ABI. After a couple of false starts and discussion with some of the helpful toolchain and ABI folks in ARM, I think we have a solution that will work well in the long term. I just wish we'd thought about this *way* back when we first started the armhf port, as it would have been much easier to work on and standardise this back then. Modulo availability of time machines, there's not much we can do on that front... :-) What I'm proposing is to use two new values in the OSABI field in the ELF header: #define ELFOSABI_LINUX_ARM_AEABI_SF 65 #define ELFOSABI_LINUX_ARM_AEABI_HF 66 and use these values in the future for soft- and hard-float binaries so that can unambiguously identify them. There's already precedent for binaries using different values in this field, with support in glibc for parsing and understanding them. Adding more possible values is quite easy, assuming that the maintainers are amenable. I'm about to post a similar message there. I have a plan of attack for how to make a staged switch over, deliberately to minimise any potential compatibility problems. See the attached doc for that. It's deliberately not very specific in terms of timeline, as that's something I'm hoping to get feedback about. Comments very welcome; please point out if you think there are problems with this approach, or if there are any more implementations of toolchain / linker that will need to be addressed. Cheers, -- Steve McIntyre steve.mcint...@linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Step 1 ====== Add new value for ARM into the allowed space for the OSABI field. Names/values *not* finalised yet, but proposing: #define ELFOSABI_LINUX_ARM_AEABI_SF 65 #define ELFOSABI_LINUX_ARM_AEABI_HF 66 These will go into a new version of the "Linux for The ARM Architecture" ARM ABI supplement (https://sourcery.mentor.com/GNUToolchain/kbattach142/arm_gnu_linux_abi.pdf) Step 2 ====== Add support for those into all the runtime linkers: * (e)glibc * uclibc (not needed AFAICS, currently ignores OSABI) * klibc (not needed AFAICS, too simple to care) * bionic (not needed AFAICS, too simple to care) * others...? For now, support/recognition of these new values will be a no-op, matching and working in just the same way as existing ARM entries. Interoperability is key for now; we don't want to break anything that currently exists. Step 3 ====== After all of the linkers have released new versions, tweak binutils and other toolchains to generate the new values(s) for SF/HF ABI binaries as appropriate: * GNU binutils * ARM toolchains * others? Step 4 ====== Add code into the linkers to differentiate based on the new OSABI values. For objects still using the old values, continue working as previously; assume nothing about them, they'll work by default. In Debian/Ubuntu we'll keep the attributes-checking code to distinguish so we can have multi-arch working. For objects using the new values, we will (finally!) be able to unambiguously determine which variant of the ABI they are using. Step 5 ====== (Potentially) after a few years, remove the Debian/Ubuntu hacks. Maybe. TBD later after review... History ======= 2012-08-01 0.1 Initial draft 2012-08-02 0.2 Trivial wording tweaks after first discussion, investigated bionic Steve McIntyre steve.mcint...@linaro.org
