Sources Bugzilla – Bug 12913
Should rename ELFOSABI_LINUX into ELFOSABI_GNU, and drop ELFOSABI_HURD
Last modified: 2012-04-09 17:10:06 UTC
H.J. Lu added separate ELFOSABI_LINUX and _HURD definitions, but these
are actually meant to be the same: the dynamic linker is the same in
both cases, from glibc, with the same "GNU" extensions.
A recent change (http://sourceware.org/bugzilla/show_bug.cgi?id=10549)
made this issue apparent eventually. Roland says we should simply
rename the existing ELFOSABI_LINUX into ELFOSABI_GNU, and remove
ELFOSABI_HURD. The attached patch does this (but keeps ELFOSABI_LINUX
as an alias for software which may already be using it).
There is no patch. Also you should also send an email to:
Created attachment 5804 [details]
Rename ELFOSABI_LINUX into ELFOSABI_GNU, drop _HURD
Hum, apparently the bugtracker doesn't give any warning that it requires an attachment description, and simply drops the attached file, nice... Anyway, here it is.
(In reply to comment #2)
> Created attachment 5804 [details]
> Rename ELFOSABI_LINUX into ELFOSABI_GNU, drop _HURD
> Hum, apparently the bugtracker doesn't give any warning that it requires an
> attachment description, and simply drops the attached file, nice... Anyway,
> here it is.
1. You should keep Linux as an alias for GNU forever
and everywhere, including the command line option for
2. You should send your patch to the binutils mailing
Created attachment 5805 [details]
Rename ELFOSABI_LINUX into ELFOSABI_GNU, drop _HURD
Here it is with elfedit alias being kept. I'll submit to the binutils
This looks very wrong. elf_osabi identifies the kernel, not userland. This commit broke elf32-i386-freebsd and elf64-x86-64-freebsd targets.
As you can see in the definition of those targets (in bfd/elf64-x86-64.c), elf_osabi field is reset to ELFOSABI_FREEBSD. This is because the kernel of FreeBSD uses osabi to identify the syscall ABI in loaded executables.
Because of this both FreeBSD and GNU/kFreeBSD have to use this tag. The way you just redefined it to imply userland rather than kernel leaves GNU/kFreeBSD out in the cold. Now we're going to hit trouble every time someone uses ELFOSABI_GNU to check for a GNU feature, and it begins right now with STT_GNU_IFUNC.
Please, can you reconsider this? There were already ways to check for userland (ELF Notes). There's no need to redefine existing interfaces to archieve that.
> This looks very wrong. elf_osabi identifies the kernel, not userland.
| Byte e_ident[EI_OSABI] identifies the OS- or ABI-specific ELF
| extensions used by this file. 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. If the object file does not use any extensions, it is
| recommended that this byte be set to 0.
> As you can see in the definition of those targets (in bfd/elf64-x86-64.c),
> elf_osabi field is reset to ELFOSABI_FREEBSD. This is because the kernel of
> FreeBSD uses osabi to identify the syscall ABI in loaded executables.
How would this have worked before? The value 0 (ELFOSABI_NONE) is used
for nearly all ELF files on GNU systems (GNU/Linux, GNU/Hurd) that don't
need any special handling.
> The way you
> just redefined it to imply userland rather than kernel leaves GNU/kFreeBSD out
> in the cold.
In my reading of the ELF standard, using ELFOSABI_GNU for an
»ABI-specific ELF extension« is fine.
(In reply to comment #7)
> How would this have worked before? The value 0 (ELFOSABI_NONE) is used
> for nearly all ELF files on GNU systems (GNU/Linux, GNU/Hurd) that don't
> need any special handling.
That's not the point. The problem is that meaning of e_ident[EI_OSABI] has been redefined. Previously when ELF said "operating system", it was asssumed that different OSes that share only the kernel (e.g. FreeBSD and GNU/kFreeBSD) also shared the same OSABI number, and different OSes that share the userland (e.g. GNU/Linux and GNU/kFreeBSD) didn't had to have a common OSABI number.
The FreeBSD project followed this convention by using OSABI to identify, during executable load by the kernel, which syscall ABI was going to be required by the new process.
OTOH GNU project disregarded that tag and promoted use of ELFOSABI_NONE.
This disparity caused minor nuissances, but it was bearable.
Then with this change, you're redefining what OSABI means. Redefining an ABI that's been strongly relied on for decades is a big no-no. Only the fact that you had to rename ELFOSABI_LINUX to ELFOSABI_GNU should hint that there's something really wrong with this change.
Now we're stuck in a situation in which we can't be a "GNU system" and a "kFreeBSD-based system" at the same time. If the GNU toolchain adds features that depend on GNU userland being present, it will check for ELFOSABI_GNU. But our binaries can't be ELFOSABI_GNU, because the kernel wants them to be ELFOSABI_FREEBSD.
So to answer your question: how could this have worked before? Well, the whole OS identification conventions worked because we didn't have contradicting ideas on what OSABI means. Now they don't work anymore. This specific feature? I don't think it worked before. The real question is: if we wanted it to work, how can we do this, now that it's impossible to satisfy the runtime checks?
Or something even more worrying: right now it's an optional feature. We could easily opt out of it, but that will happen when it's not an optional feature, but a mandatory requirement that depends on ELFOSABI_GNU? The way you're laying things out, it's certainly possible that this happens someday.
It may have been an unfortunate choice to use EI_OSABI for the meaning that ELFOSABI_GNU has. But it's already been done and it's too late now.
At any rate, this is not the place to discuss such decisions.
You can open the subject on the binutils and libc-alpha lists if you want.
(In reply to comment #9)
> It may have been an unfortunate choice to use EI_OSABI for the meaning that
> ELFOSABI_GNU has.
You could have asked...
> But it's already been done and it's too late now.
Can you be more specific? I'd really like to see a technical explanation on that.
> At any rate, this is not the place to discuss such decisions.
> You can open the subject on the binutils and libc-alpha lists if you want.
Fine. Which one do we move to, libc-alpha?