[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ELFOSABI_GNU mess. Please advice...

El 7 d’abril de 2012 23:13, Robert Millan <rmh@debian.org> ha escrit:
> See my message in http://sourceware.org/bugzilla/show_bug.cgi?id=12913#c6

This really needs a lot more attention, it's not just a toolchain bug
causing FTBFS in gcc.


binutils/gcc/glibc redefined the meaning of ELF osabi field.  The new
meaning contradicts the one assumed by kernel of FreeBSD.  Now on
GNU/kFreeBSD it happens that userland thinks osabi field identifies
userland, and kernel thinks osabi field identifies kernel.

We've lived perfectly well with kernel having the ELFOSABI_FREEBSD (9)
requirement for executing binaries, since userland didn't care about
ELFOSABI at all.  I think to the date GNU/Linux has been using
ELFOSABI_NONE (0), rather than ELFOSABI_LINUX (3).

Now ELFOSABI_LINUX (3) has been unilaterally redefined. It's now a
(deprecated) alias for ELFOSABI_GNU, and it implies GNU userland.
Toolchain components begin to use it to check for availability of GNU
features.  We just found binutils doing this, since binutils is only
writing this information it's to be expected that something else [1]
(gcc? glibc?) is reading it and requires ELFOSABI_GNU.

Unfortunately we can't just switch to ELFOSABI_GNU because the kernel
won't identify those binaries as native FreeBSD syscall ABI.

I've written a bandaid for binutils.  But I'm not sure if that will be
enough.  I'm worried that runtime errors begin to appear somewhere
else, because we don't have the "correct" ELFOSABI.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10549

Robert Millan

Attachment: binutils.diff
Description: Binary data

Reply to: