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

Erm, yes, I realised they weren't that different, shortly after I posted 
it.

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

Yes, that would work; EI_ABIVERSION values are specific to a particular 
EI_OSABI value.  We should probably adopt 0 for the current stuff (meaning 
no (unknown) version) then 1 when we stabilize.

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

I can't say for certain, but I think if the only difference is enum size, 
there's unlikely to be much, if anything, that crosses the kernel boundary 
that would be affected.