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