This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Elf OS ABI Number
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: "Kris Warkentin" <kewarken at qnx dot com>
- Cc: Richard dot Earnshaw at arm dot com, "Gdb at Sources dot Redhat dot Com" <gdb at sources dot redhat dot com>
- Date: Thu, 12 Jun 2003 15:27:19 +0100
- Subject: Re: Elf OS ABI Number
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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.