RFC: Changing ELFOSABI_FREEBSD into ELFOSABI_SYSV/ELFOSABI_NONE

[Aurelien Jarno]

Hi all,

I am currently trying to reduce the number of 'ugly-hacks' patches. I am
investigating the 'elfosabi.patch' that you can find below:

--- elf/dl-load.c.orig	2005-08-24 01:45:36.000000000 +0200
+++ elf/dl-load.c	2005-08-18 16:54:47.000000000 +0200
@@ -1495,7 +1495,7 @@
     [EI_CLASS] = ELFW(CLASS),
     [EI_DATA] = byteorder,
     [EI_VERSION] = EV_CURRENT,
-    [EI_OSABI] = ELFOSABI_SYSV,
+    [EI_OSABI] = ELFOSABI_FREEBSD,
     [EI_ABIVERSION] = 0
   };
   static const struct

As you can see, it changes the OSABI to ELFOSABI_FREEBSD. It seems that
other OS based on GNU libc are using the ELFOSABI_SYSV, that is also
known as ELFOSABI_NONE. This is true for at least GNU/Linux, GNU/Hurd
and GNU/Opensolaris. Note that an ELFOSABI_LINUX exists, and there is
trace of an ELFOSABI_HURD in binutils.

I wonder why GNU/kFreeBSD is currently using a ELFOSABI_FREEBSD and not a
ELFOSABI_SYSV OSABI. Probably because the kernel refuse to execute the
executables with the later ABI. Maybe there is other reasons?


I am currently thinking of changing the default OSABI to ELFOSABI_SYSV, 
while still making the kernel able to execute ELFOSABI_FREEBSD, as we 
want to be able to execute plain FreeBSD binaries.


This will probably help us to be able to support other kernels (such as 
NetBSD) as explained below. 

Currently FreeBSD executes the binaries as follow:
 ELFOSABI_FREEBSD: native
 ELFOSABI_LINUX: Linux compatibility layer
 other: error message like 'ELF binary type "0" not known.'

If we want to add support to NetBSD kernel [1], we could either use 
the FreeBSD compatibility layer, but it we will be limited. Moreover we
need to port the changes we made into the FreeBSD kernel (such as 
linuxthreads signals) into the compatibility layer, that sounds a bit
ugly, and we may have technical problem. That would mean that we need
to use bi-arch, and to the compatibility via the GNU libc. That would 
also mean that we need to make the NetBSD kernel to execute 
ELFOSABI_FREEBSD as native. It would then execute the binaries as 
follow:
 ELFOSABI_NETBSD: native
 ELFOSABI_FREEBSD: native (that's ugly!)
 ELFOSABI_LINUX: Linux compatibility layer
 other: error message

That would mean we lost the possibility to execute plain FreeBSD 
binaries.

Now consider changing the default OSABI to ELFOSABI_SYSV:
FreeBSD kernel:
 ELFOSABI_SYSV: native
 ELFOSABI_FREEBSD: native
 ELFOSABI_LINUX: Linux compatibility layer
 other: error message like 'ELF interpreter /lib/ld-linux.so.2 not
 found'

NetBSD kernel:
 ELFOSABI_SYSV: native
 ELFOSABI_NETBSD: native
 ELFOSABI_FREEBSD: FreeBSD compatibility layer
 ELFOSABI_LINUX: Linux compatibility layer
 other: error message

This way, we don't loose any functionality. Note that this example also 
applies to other kernels than NetBSD (eg. OpenBSD).


Here is how I think we could implement this change:
 * Make changes to the kernel to execute ELFOSABI_SYSV as native.
 * Make the Debian glibc to be able to execute both ELFOSABI_SYSV
   and ELFOSABI_FREEBSD. But only send the ELFOSABI_SYSV to upstream.
 * Change binutils to use ELFOSABI_SYSV as default.
 * Rebuilt all packages (it can be delayed, see below).

Note that we don't break anything until we remove the compatibility 
stuff in glibc. However, users will have to upgrade their kernel before,
or as the same time as the new glibc.

Advantages:
 * Consistent with other OS using GNU libc.
 * Better support of multiple kernels.
 * We don't need to make this ugly change in GNU libc.
 * We will be able to make the kernel to behave differently for 
   ELFOSABI_FREEBSD and ELFOSABI_SYSV. That's mean that if we make 
   incompatible changes in the kernel, it would still be possible to 
   have a FreeBSD chroot on a GNU/kFreeBSD system.

Drawbacks:
 * We need to patch binutils and the maintainer is not really 
   responsive. (In case of problem, we can wait for the patch to be
   accepted upstream, and find a problem in the current binutils. 
   Elmo will package a new CVS version :).
 * Users will need to upgrade their kernel (changes implying a kernel
   upgrade has already been done in the past).
 * System won't be functional anymore when we will remove the glibc 
   hack if all the packages have not been upgraded (we can keep the 
   patch for a long time, something like 1 or 2 years).
 * All packages will need to be rebuilt with the new OSABI to be able
   to run another kernel (is it really a problem?).
 * Users will get an 'ELF interpreter /lib/ld-linux.so.2 not found' 
   instead of 'ELF binary type "0" not known.' if they don't use 
   freebsd-brandelf on their Linux binaries (is it really a problem?).
 * It won't be possible to use a GNU/kFreeBSD chroot on a plain FreeBSD
   system, but that's actually already the case, due to at least our
   linuxthread and our ET_DYN patch. The reverse is possible though.

Even if there is a lot of drawbacks, I consider all of them as minor, 
that's why I propose to change the OSABI in GNU/kFreeBSD.


I am waiting for your comments. I don't know what will be the choice, 
but IMHO, it has to be done now, ie before we sent patches for glibc to
Debian and upstream, and before the integration into the Debian archive.

Bye,
Aurelien


[1] I think that the restriction that Anthony Towns imposes to be able to
    enter to the archive, ie ability to have bi-arch with GNU/kNetBSD is a
    good idea, because:
    - Users already regularly ask that for Linux vs kFreeBSD
    - Multiplying the architectures into Debian is not really a good 
      idea. It implies more work to maintain all the ports, and also
      more archive space.
    - That's a first step to gnu-any :)

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32 at debian.org         | aurelien at aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net