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 18:31, Jason R Thorpe wrote:
> On Sun, Apr 07, 2002 at 11:17:31AM +0100, Philip Blundell wrote:
> 
>  > That is not really what the EI_OSABI field is for.  It is intended to
>  > identify the ABI in a wider sense, so that you can ascribe meanings to
>  > things like reloc numbers.  If your object files are compatible with
>  > what elfarm-nabi.c produces, you should stick with ELFOSABI_ARM.
> 
> Err, this certainly doesn't appear to be the case with e.g. elf-hppa-linux.
> As far as I can tell, the usage of EI_OSABI in that code is basically the
> same as the usage I have in mind for elfarm-nabi.

Really?  The HPPA situation seems to be that they have some ELF
extensions that are incompatible with the base ABI.  See, for example,
http://sources.redhat.com/ml/binutils/2000-11/msg00371.html.

>  > What were you planning to use this identification for?  Is it just to
>  > stop people from accidentally linking together incompatible objects, or
>  > is there something else?
> 
> When we transition to the ARM EABI later, the dynamic linker will be
> able find compatibility shlibs for existing programs using the EI_OSABI
> field.

I'm sure there are other ways you could arrange this.  The simplest,
though admittedly intrusive, way would be to change the sonames of all
your shared objects.  Other than that, you can use the name of the
program interpreter or libc to effectively brand your libraries as being
for one ABI or the other -- I think the latter is what was used for the
libc5 -> libc6 migration on i386-linux, though that's long enough ago
now that my recollection is a bit fuzzy.  Or you just accept that
compatibility shlibs will always live in some well-defined location,
/lib/oabi/ or whatever, and have the "old ABI" dynamic linker search
that first when it's looking for libraries.

In fact, if this is all you are interested in you could probably use
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.  (I still
don't think it's a particularly good idea to use it for what you're
proposing, but ...)

p.