From: John Marvin <jsm@udlkern.fc.hp.com>
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] Use of the EI_OSABI field
Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) [thread overview]
Message-ID: <200011210547.WAA18159@udlkern.fc.hp.com> (raw)
> 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
next reply other threads:[~2000-11-21 5:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-21 5:47 John Marvin [this message]
2000-11-21 22:50 ` [parisc-linux] Use of the EI_OSABI field Alan Modra
2000-11-21 23:27 ` Ulrich Drepper
2000-11-22 0:13 ` Alan Modra
2000-11-22 0:31 ` Ulrich Drepper
2000-11-22 0:53 ` H . J . Lu
2000-11-22 3:03 ` Alan Modra
2000-11-22 3:11 ` H . J . Lu
2000-11-25 20:28 ` David O'Brien
2000-11-25 20:33 ` H . J . Lu
2000-11-22 3:18 ` Ulrich Drepper
2000-11-25 20:31 ` David O'Brien
2000-11-25 20:22 ` David O'Brien
-- strict thread matches above, loose matches on Subject: below --
2000-11-22 8:52 John Marvin
2000-11-22 18:06 Cary Coutant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200011210547.WAA18159@udlkern.fc.hp.com \
--to=jsm@udlkern.fc.hp.com \
--cc=parisc-linux@puffin.external.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox