Linux PARISC architecture development
 help / color / mirror / Atom feed
* [parisc-linux] Use of the EI_OSABI field
@ 2000-11-21  5:47 John Marvin
  2000-11-21 22:50 ` Alan Modra
  0 siblings, 1 reply; 15+ messages in thread
From: John Marvin @ 2000-11-21  5:47 UTC (permalink / raw)
  To: parisc-linux

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [parisc-linux] Use of the EI_OSABI field
@ 2000-11-22  8:52 John Marvin
  0 siblings, 0 replies; 15+ messages in thread
From: John Marvin @ 2000-11-22  8:52 UTC (permalink / raw)
  To: parisc-linux

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

I didn't say it was difficult, I said it was ugly. It means another
parisc only change to the machine independent file fs/binfmt_elf.c,
since the hook provided will not allow this check. Without a change,
binfmt_elf.c won't be smart enough to differentiate a binary produced
by Gnu binutils for HP-UX and a binary produced by Gnu binutils for
Linux, so it will claim both, and then blow up later, rather than
not claiming the HP-UX binary and allowing it to be claimed by
an arch dependent binary handler further down the list.

And binfmt_elf.c does NOT read the program headers in the same read, so
another read would have to be done (the data should be found in in cache
rather than going to disk for it). Since we now need both the program
headers and a section header to determine whether or not we should claim
the file AND binfmt_elf.c also wants to look at those headers after
the file is claimed, a small redesign is probably in order (rather than
re-reading the headers). I'm not sure whether or not Linus would buy
that.

So, I guess I'll pursue the interpreter field instead, since that is
what sparc is doing (i.e. they have their own sparc only code in
binfmt_elf.c). Since that will be an easier sell. I need to do more
research here. I suspect that statically linked binaries are not going
to allow this solution to work though.

John Marvin
jsm@fc.hp.com

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [parisc-linux] Use of the EI_OSABI field
@ 2000-11-22 18:06 Cary Coutant
  0 siblings, 0 replies; 15+ messages in thread
From: Cary Coutant @ 2000-11-22 18:06 UTC (permalink / raw)
  To: H . J . Lu, Alan Modra
  Cc: Ulrich Drepper, John Marvin, parisc-linux, parisc-linux, binutils

As the original author of the proposal to add the EI_OSABI field to the 
ELF format, let me try to clarify the intent of this field. The 
authoritative definition of this field is found in SCO's gABI document, 
which is still the official specification for the ELF format (this is 
probably posted somewhere on SCO's web site). Here's what it says:

    Byte e_ident[EI_OSABI] identifies the operating system and
    ABI to which the object is targeted. Some fields in other ELF
    structures have flags and values that have operating system
    and/or ABI specific meanings; the interpretation of those
    fields is determined by the value of this byte. The value of
    this byte must be interpreted differently for each machine.
    That is, each value for the e_machine field determines a set
    of values for the EI_OSABI byte. Values are assigned by the
    ABI processor supplement for each machine. If the processor
    supplement does not specify a set of values, the value 0
    shall be used and indicates unspecified.

The first sentence is still a bit misleading, and is an artifact of the 
original proposal. Originally, the field was intended to identify the 
target ABI (hence the name of the field). As we started discussing a 
common Unix ABI for IA-64, however, it became clear that this field 
wouldn't serve that purpose, but it was still needed to identify the set 
of platform-specific ELF extensions that are used by the object file.

There are a number of fields in the ELF format for which ranges of values 
or a set of flag bits are reserved for vendor-specific use (e.g., 
SHT_LOOS through SHT_HIOS for vendor-specific section types, and 
SHF_MASKOS for vendor-specific section attributes). If an object file 
uses any of these values or flag bits, the consumer of the file must 
consult the EI_OSABI field to determine what those values or flags mean. 
It works just like the e_machine field does for attaching meaning to 
processor-specific values and flags.

The intent is that any ABI-conforming implementation will be able to 
execute an ABI-conforming binary, even if it uses certain vendor-specific 
features. In many cases, those vendor-specific features are hints for a 
particular OS that can be ignored by other implementations. Where this is 
not the case, and a vendor-specific feature must be understood by the 
system in order to process the file correctly, we have a couple of 
alternatives.

For section types and flags that a linker must understand, we have the 
SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a 
particular section type or flag, it must reject the file.

For executables that will execute only on a particular implementation, we 
must use an alternate interpreter (PT_INTERP) or bind to 
implementation-specific shared libraries. An ABI-conforming binary will 
use the interpreter specified in the psABI spec, and will use only system 
libraries specified there.

For statically-bound programs, I'm afraid we don't have a clear solution. 
We took the general approach that such programs are not ABI-conforming in 
the first place, and can use any mechanism they might choose to verify 
that they are executing on the appropriate implementation.

-cary

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2000-11-25 20:31 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-11-21  5:47 [parisc-linux] Use of the EI_OSABI field John Marvin
2000-11-21 22:50 ` 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox