Re: [PATCH/RFA] Mark arm-*-netbsdelf* binaries as ELFOSABI_NETBSD

[Philip Blundell <pb at nexus dot co dot uk>]

On Sun, 2002-04-07 at 22:51, Jason R Thorpe wrote:
> On Sun, Apr 07, 2002 at 10:21:51PM +0100, Philip Blundell wrote:
>  > EI_OSABI without introducing any new values.  You can take ELFOSABI_ARM
>  > to mean your existing ABI, and assume that at the point binutils adopts
>  > an "official" ARM EABI it will start writing EI_OSABI as zero. 
> 
> Is this was binutils is going to do?  

I believe so, yes.

The reason for switching to ELFOSABI_ARM in the first place was that
armelf-oabi and armelf-nabit really do have different semantics for
their relocations.  Assuming that other ARM vendors are writing this
field out as zero, we now have two problems: firstly, their tools may -
perhaps should - not want to touch binaries created by GNU binutils;
secondly, and maybe worse, any foreign objects will appear to BFD as the
"oabi" variant, which will make the GNU linker botch its relocations.

Once there is a worthwhile common EABI, this artificial barrier to
compatibility will become much more embarrassing, plus I think we are
pretty much at the point where we can discontinue support for the "oabi"
with a fairly clear conscience.  As far as I know it was only ever used
by a few Cygnus customers.  So I'm pretty clear that the right thing to
do is to go back to ELFOSABI_NONE at the point the new ABI is adopted.  

> (Note, I'm pretty sure the EABI is only going to affect things like
> register usage, enum packing, etc., and isn't going to change how 
> e.g. relocs work, 

As a matter of fact I think there is a reasonable chance it will end up
changing the way some of the GNU/Linux PIC relocs work.  Even if that
weren't the case, though, the way to indicate conformance to the ABI is
to set EI_OSABI to zero, and that's what we should do.

p.