On Tue, 26 Mar 2002, Richard Earnshaw wrote:

> thorpej@wasabisystems.com said:
> > 	* 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:

As far as I can see, it's pretty much equivalent apart from EI_OSABI
quibbling, so I have no problem with it.

> 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).
> 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.

Erm, why not use ELFOSABI_NETBSD in both cases, and use EI_ABIVERSION to
distinguish?

> 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.

It'd be nice if we could get away without having to have kernel support
for this (e.g. by doing trickery in the dynamic linker, or changing the
PT_INTERP name).

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>