Subject: Re: The ELF ABI issue
To: None <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 03/26/2002 16:17:42
> * Effectively reject the ARM eABI at this time, instead picking
> our own sane ABI. This means not using packed-enums (I actually
> backed out the packed-enum change to the compiler a few minutes
> ago), and picking our own thread-local-storage register now.
> * Mark our ELF objects/execuables as ELFOSABI_NETBSD, to distinguish
> it from the official ARM ABI. This is the correct use of the
> EI_OSABI field in the ELF header.
> * When the ARM eABI is finalized, add support in our dynamic linker
> for allowing only objects of the same EI_OSABI to be linked.
> This allows us to support the ARM eABI in the future.
OK, here's a counter-proposal:
1) We implement 1.6 with a *temporary* ABI, that doesn't use packed enums,
or a TLS register.
2) We do not mark the executables (or object files) with the
ELFOSABI_NETBSD value (we leave it at 0).
3) For 1.7 we adopt the full eABI (assuming that it really is published by
then -- I expect it to be).
4) We continue support the 1.6 abi by using an emulation for it, as we
would for a linux executable etc.
5) For the 1.7 ABI (or whenever we get to the final ABI) we DO set
ELFOSABI_NETBSD, so that we can distinguish the two sets of executables.
the implications of this are that object files for 1.6 and 1.7 won't be
compatible, but executable images will still work. A person upgrading
from 1.6 to 1.7 will have to install compatibility libraries, as they
would if installing Linux support.
This would mean that eventually the need to support the incompatible ABI
will go away and we will be left with a conforming system. I can't be
certain, but I suspect that the number of kernel calls affected by enums
would be small to zero, so the overhead of supporting old applications in
the kernel will be minimal.
Finally, we document that this is what we are doing, so nobody has the
right to be upset after the fact...