On 2 August 2012 17:43, Steve McIntyre steve.mcintyre@linaro.org wrote:
[ Also posted to debian-arm; not cross-posted to avoid subscription complaints... ]
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.
Nevertheless, the tags in the .ARM.attributes section are the standard, published way to identify FP ABI as well as a number of other properties that might be relevant to a linker.
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.
What happens if this value doesn't match the Tag_ABI_VFP_args value in .ARM.attributes? If the same information is present in multiple places, sooner or later someone will manage to create a file with a mismatch.
This approach is also not scalable. Suppose one day it becomes desirable to add ld.so awareness of some other feature. Then you'd need two more values to cover all the combinations. Add another feature, and you need 8 values. You get the picture.
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 really think the only sane thing to do is fix glibc so it can fetch the attributes from their standard locations.