Subject: The ELF ABI issue
To: None <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 03/25/2002 15:36:04
So, even after much work to deal with the packed-enum issue, there are
still problems in the source tree with packed-enums. Finding them all
is going to take a long time.
In addition, ARM still hasn't finalized the eABI. We'd like to comply
with it, but at this point, we have no guarantees that ARM won't flip-flop
on packed-enums, thread-local-storage, etc.
I did not anticipate this much lossage when I previously advocated sticking
to the ARM eABI.
So, after discussing this situation with Ben today, I'd like to propose
* 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.
Ben pretty much agreed with this proposal. I'd like to get buy-in on this
SOON so that we can actually release all of our ARM platforms in 1.6.
If we do decide to go this way, the only thing to do is pick the thread
local storage register... sounded like ARM was thinking of r9 or r10.
I say we just pick r10.
-- Jason R. Thorpe <email@example.com>