[parisc-linux] Use of the EI_OSABI field

[Alan Modra]

cc to binutils because John makes some salient points.

On Mon, 20 Nov 2000, John Marvin wrote:

> > Another glibc issue (which is why I'm sending this back to the list) is
> > that there has been quite some discussion on the binutils list over the
> > use of the EI_OSABI field.  The conclusion being that it isn't really
> > correct to use this field to discern the intendend execution platform.
> > It's purpose is really to tell ELF tools that a file contains fields and
> > values that need to be interpreted in a non-standard way.  Since both
> > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that
> > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets.
> 
> I don't read the binutils mailing list, so I checked the archive.  In my
> opinion I didn't see a discussion, I saw H.J.  Lu repeatedly asserting
> this "fact".  He may or may not be correct about original intention, but
> the implementation so far has been that EI_OSABI is used to tell what the
> target platform is.  That is what FreeBSD is doing, that is what HP-UX is
> doing, and that is what the IA-64 Unix System V Application Binary
> Interface specifies:
> 
>   http://developer.intel.com/design/IA-64/Downloads/24537002.pdf
> 
> Note that the second paragraph in section 1.1 of that specification
> includes the following:
> 
>     This document is the result of consensus among operating system
>     vendors intending to provide UNIX and UNIX workalike operating
>     systems on the IA-64 architecture. The vendors participating in
>     this effort include Intel, Sun Microsystems, SCO, IBM, SGI,
>     Cygnus Solutions, VA Linux Systems, HP, and Compaq.
> 
> So, If the specification is wrong according to H.J. Lu, why did both
> Cygnus and VA Linux Systems not object to this:
> 
>     Section 4.1.1.4 Operating System Identification
> 
>     The e_ident[EI_OSABI] value identifies the operating system and
>     ABI to which the object is targeted, as listed in Table 4-1.
> 
> Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX,
> ELFOSABI_NETBSD, ELFOSABI_LINUX, etc.
> 
> Note also, that the current mechanism for us to be able to differentiate
> elf executables in the Linux kernel is the machine dependent
> elf_check_arch() macro, whose only argument is a pointer to a
> elf32_hdr or elf64_hdr. I think it would be ugly to try to get the
> .note.ABI-tag section first for every exec of a new binary in order
> to determine what the target ABI is.
> 
> In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too
> late to assert his view of what that field was supposed to be. Please
> leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus
> on this issue is reached.
> 
> John Marvin
> jsm@fc.hp.com

I'm happy enough to leave things as they are in puffin CVS, but these
changes haven't been merged back to sourceware yet, partly because I had
some doubts myself as to whether setting EI_OSABI was correct.  H.J. Lu
wasn't the only one arguing that EI_OSABI should be left at zero;  Ulrich
Drepper also was quite vehement against changing sourceware FreeBSD
binutils.

BTW, it's not too hard to check .note.ABI-tag.  The linker arranges for a
PT_NOTE program header entry to point to it, and the section itself is
virtually guaranteed to be read in with the header as it's placed right
after the header along with .interp.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.