RFC: Changing ELFOSABI_FREEBSD into ELFOSABI_SYSV/ELFOSABI_NONE
Aurelien Jarno
aurelien at aurel32.net
Wed Jan 4 06:10:14 UTC 2006
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
More information about the Glibc-bsd-devel
mailing list