Subject: Re: The ELF ABI issue
To: Ben Harris <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 03/26/2002 16:45:51
> On Tue, 26 Mar 2002, Richard Earnshaw wrote:
> > email@example.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
> Erm, why not use ELFOSABI_NETBSD in both cases, and use EI_ABIVERSION to
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.