ARM hard-float ABI: add ldconfig flag value

[Steve McIntyre]

On Fri, Jul 27, 2012 at 05:09:53PM +0100, Steve McIntyre wrote:
>Hi,
>
>I'm back to working on some of the HF ABI issues that have been raised
>in the past [1]; sorry for the long delay. As a first part, here's a
>trivial patch to add a flag value for HF ABI libraries in ldconfig and
>the cache:
>
>diff --git a/sysdeps/generic/ldconfig.h b/sysdeps/generic/ldconfig.h
>index ef3f4b9..1cffdc6 100644
>--- a/sysdeps/generic/ldconfig.h
>+++ b/sysdeps/generic/ldconfig.h
>@@ -34,6 +34,7 @@
> #define FLAG_MIPS64_LIBN32     0x0600
> #define FLAG_MIPS64_LIBN64     0x0700
> #define FLAG_X8664_LIBX32      0x0800
>+#define FLAG_ARM_HFABI         0x0900
> 
> /* Name of auxiliary cache.  */
> #define _PATH_LDCONFIG_AUX_CACHE "/var/cache/ldconfig/aux-cache"
>
>
>I'm discussing a possible use/implementation of the PT_ARM_ARCHEXT
>segment with folks inside ARM at the moment, as a replacement for
>checking the ARM-specific build attributes that people didn't like
>back then. In advance of that, I'd like to stake a claim for a flag
>value. I'm guessing that the new ARM AArch64 architecture will need
>one too, but I'll leave that for the team to ask about separately when
>they're ready.
>
>[1] http://www.eglibc.org/archives/patches/msg01017.html

Hi folks,

I've not seen any comments on this at all. I'm hoping it's not *that*
scary...!?

I've also been discussing with the ARM ABI folks about how to identify
whether a binary is hard-float or soft-float. The PT_ARM_ARCHEXT
approach might work, but it's felt to be more complicated than
necessary. Our favoured approach is to add two new possible values for
the OSABI field. I just wish that people had thought about this *way*
back when we first started the hard-float ABI work, 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 today...

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.

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.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
-------------- next part --------------
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.mcintyre@linaro.org