This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Apr 07, 2002 at 10:21:51PM +0100, Philip Blundell wrote:

 > 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.

NetBSD doesn't work this way.  The dynamic linker doesn't have a version
number (there's really no good reason for it to do so), and the library
versioning rules NetBSD uses specifically don't allow version skew between
architectures.  (This sort of cross-platform consistency is an indispensable
feature to our user base.)

Anyway, yes, the intent once the EABI was finalized and adopted was to have
the dynamic linker look in /emul/armelf_osabi_netbsd/usr/lib/... if it notices
program being run is ELFOSABI_NETBSD.  (We have a similar transition mechanism
for a.out -> ELF transition on platforms that started life as a.out.)

 > 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 ...)

Is this was binutils is going to do?  (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, i.e. the stuff that you
and H.J. are claiming the EI_OSABI field is actually intended for, so by
your own argument, binutils wouldn't do what you just proposed).

...and, actually, isn't EI_OSABI of 0 alreay used by ARM binutils to mean
"oabi"?

Sigh, this is annoying ... Richard Earnshaw and I disucssed this at length,
and we both came to the conclusion that it was perfectly legitimate to use
EI_OSABI field for this purpose... :-/

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]