Re: Elf OS ABI Number

[Richard Earnshaw <rearnsha@arm.com>]

> > > Does anyone know how to get one of these?  I was rooting around on
> Caldera's
> > > website but didn't see anything.  I've realized that we need to have a
> > > practical way to identify QNX binaries and this looks like the way to
> go.
> > >
> >
> > A fairly common question, to which most times the answer is that you don't
> > need one.
> >
> > You should only be using the OS ABI field if you are changing the meaning
> > of the ELF specifics for a processor (new relocs, for example) which a
> > linker not trained to recognise these would be unable to handle.  It
> > shouldn't be used to represent things that are encoded in the instructions
> > inside sections (eg library calls specific to your OS, etc).
> 
> Actually, we do have a few things that are different - QNX specific
> relocations, different MIPS ABI, etc.  It seems like having the ABI number
> can do no harm but can certainly be useful. 

As I said before, new relocations is a valid reason for an OS_ABI field 
change.  However, an ABI change (calling standard) is not -- it doesn't 
change the meaning of the ELF container, which is what the field is about. 
 The harm is that a linker is supposed to reject an OS_ABI field setting 
it doesn't understand.

Is there a good reason why you've invented your own relocs?  If the 
processor vendor (who generally own the reloc space allocation for their 
processor) where to allocate a reloc that conflicts with your usage at a 
later date you might have a major problem on your hands.

> The problem with things like
> .note sections for identifying binaries is that a stripped binary can no
> longer be identified.

No, .note sections are not symbols, so are not removed by strip.  The only 
way to remove a .note section is to use objcopy and tell it not to copy 
that section.

R.