[parisc-linux] ELFOSABI_LINUX

[parisc-linux] ELFOSABI_LINUX

[Matthew Wilcox]

Here's the current situation as I understand it.

 * Binutils, when configured for an hppa-linux target, outputs binaries
   with the EI_OSABI field set to ELFOSABI_LINUX instead of ELFOSABI_SYSV.

 * The dynamic linker will refuse to link binaries for which the EI_OSABI
   field doesn't match the expected values -- the patch Jes wrote last
   december checks this field is set to either SYSV or LINUX, whereas
   the standard check is just for SYSV.  (note this is hppa-linux only
   and affects no other architecture).

 * The kernel does not currently check the EI_OSABI field.

The original discussion last November seemed to reach a resolution that
using this field to mark which ABI the OS implements was not the right
thing; instead this field marks ELF extensions that the ELF tools must
be aware of before manipulating this file.

Now, I'm not interested in digging up who did what when and why in order to
get us into this state.  But we do have a problem here.  Either we need to:

 * Stay in violation of the interpretation of the spec proposed last
   November.  This implies adding the HPPA patch to glibc so ld.so will
   recognise ELFOSABI_LINUX binaries.

 * Change binutils to produce binaries without ELFOSABI_LINUX set.  This
   implies rebuilding every debian package we've built so far -- over
   1100 source packages.  This means we'd miss our deadline of shipping
   at the end of May.

One subversive developer suggested a third alternative -- that we think up
& implement an extension to the ABI so we have to use ELFOSABI_LINUX :-)

Thoughts?

Re: [parisc-linux] ELFOSABI_LINUX

[Cary Coutant]

>One subversive developer suggested a third alternative -- that we think up
>& implement an extension to the ABI so we have to use ELFOSABI_LINUX :-)

There's no harm in claiming to use extensions that you really don't use 
-- even if there aren't any such extensions to use. We recommend, but do 
not require, that you set the OSABI field to zero if there are no 
extensions in use.

The only downside here is that some non-Linux ELF consumer might decide 
up front that it can't read the file because it doesn't understand the 
extensions. A well-written consumer, however, will wait until it actually 
sees an extension before deciding whether or not it understands it.

-cary

Re: [parisc-linux] ELFOSABI_LINUX

[amodra]

Let's see now.

  1) We use relocations that are not mentioned in the Processor
     Specific ABI supplement, eg. R_PARISC_PCREL12F.
  2) PA-ELF32 uses relocations that the parisc psabi says are only
     used by ELF64, eg. R_PARISC_IPLT.  No big deal, except of course
     they're a different size.
  3) PA-ELF32 uses DT_INIT and DT_FINI, which the psabi specifically
     says are not used (by HPUX).  Again no big deal.
  4) HPUX sets a precedent for PARISC, and uses a non-zero OSABI value

and probably other things I haven't thought of at the moment.

Alan

Re: [parisc-linux] ELFOSABI_LINUX

[Cary Coutant]

>  1) We use relocations that are not mentioned in the Processor
>     Specific ABI supplement, eg. R_PARISC_PCREL12F.

What is the relocation number? I'll add it. (I hope it's not 13 or 73. 
We've recently added PCREL17FI and PCREL22FI, respectively.)


>  2) PA-ELF32 uses relocations that the parisc psabi says are only
>     used by ELF64, eg. R_PARISC_IPLT.  No big deal, except of course
>     they're a different size.

Is it still 129? I'll add it.

If there are any other relocations you use that aren't in HP's ELF/PA 
document, please let me know.


>  3) PA-ELF32 uses DT_INIT and DT_FINI, which the psabi specifically
>     says are not used (by HPUX).  Again no big deal.

I agree -- no big deal. The document that says they're not used is 
specifically referring to HP-UX, and was not meant to apply to other 
operating systems.


>  4) HPUX sets a precedent for PARISC, and uses a non-zero OSABI value

Well, we *do* use vendor-specific extensions. Plenty of them, in fact.


-cary

Re: [parisc-linux] ELFOSABI_LINUX

[Ulrich Drepper]

Cary Coutant <cary@cup.hp.com> writes:

> There's no harm in claiming to use extensions that you really don't use 
> -- even if there aren't any such extensions to use.

There is no harm but I won't allow it. 

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] ELFOSABI_LINUX

[Cary Coutant]

>> There's no harm in claiming to use extensions that you really don't use 
>> -- even if there aren't any such extensions to use.
>
>There is no harm but I won't allow it. 

My statement was in response to a concern expressed by Matthew that a 
change to binutils would require rebuilding every single package:

> * Change binutils to produce binaries without ELFOSABI_LINUX set.  This
>   implies rebuilding every debian package we've built so far -- over
>   1100 source packages.  This means we'd miss our deadline of shipping
>   at the end of May.

I was trying to make the point that he could fix the tools (as you seem 
to prefer), but that binaries that have already been built will still 
work. They can be rebuilt at leisure (or not at all).

-cary

Re: [parisc-linux] ELFOSABI_LINUX

[Jes Sorensen]

>>>>> "Matthew" == Matthew Wilcox <willy@ldl.fc.hp.com> writes:

Matthew>  * Change binutils to produce binaries without ELFOSABI_LINUX
Matthew> set.  This implies rebuilding every debian package we've
Matthew> built so far -- over 1100 source packages.  This means we'd
Matthew> miss our deadline of shipping at the end of May.

Matthew> One subversive developer suggested a third alternative --
Matthew> that we think up & implement an extension to the ABI so we
Matthew> have to use ELFOSABI_LINUX :-)

The easy solution is to change binutils, keep the double check for
ELFOSABI_LINUX and ELFOSABI_SYSV in the hppa glibc for a while and
nuke it when everybody has updated. The important bit is to not put a
toolchain out there that produces the wrong binaries.

I've used similar tricks on the ia64 in the past.

Jes