RFC: Changing ELFOSABI_FREEBSD into ELFOSABI_SYSV/ELFOSABI_NONE

[Robert Millan]

On Wed, Jan 04, 2006 at 07:10:14AM +0100, Aurelien Jarno wrote:
> 
> 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?

This was added by Bruno.  Note that unlike the other kernels (including
kNetBSD), kFreeBSD is using weird variant of ELF.  See what Bruno said:

  http://sourceware.org/ml/binutils/2002-07/msg00103.html

rmh at aragorn:~$ ld --help | grep "supported"
ld: supported targets: elf32-i386 [...]
ld: supported emulations: elf_i386 [...]
rmh at io:~$ ld --help | grep "supported"
ld: supported targets: elf32-i386-freebsd [...]
ld: supported emulations: elf_i386_fbsd elf_i386 [...]

Gcc is patched to pass a different -m flag for i386-kfreebsd-gnu, see

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/kfreebsd-gnu.h?rev=101314&view=markup

and

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/linux.h?rev=107347&view=markup

> 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.'

They're still elf32-i386-freebsd binaries instead of elf32-i386.  AFAIK this
macro is set to make a distinction.  If we're going to use _SYSV, I think we
should be consistent and fix the kernel to skip the 16 byte label in that case.

>  * 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.

I think that's a problem.  If we're seriously going to use _SYSV, why not doing
it in a way that upstream can accept?

(I still hope upstream accepts things like ET_DYN someday.  Specialy when
Debian GNU/kFreeBSD is released and we report that FreeBSD can't run our
binaries)

> 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.

IMHO it's a good thing to try being "less weird" and use normal _SYSV binaries,
but should be done carefuly.

> [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 :)

We could easily make a package of knetbsd which, accompanied with its own
knetbsd-loder / netbsd-utils, would boot a kfreebsd-i386 system and be able to
use most of the basic functionality.

It seems the old Debian GNU/NetBSD project's repository [1] has binaries, but
no source [2].  Anyway, kNetBSD 1.6 is now obsolete, and our kfreebsd-5-source
would probably be a good base for knetbsd (they use the same build method in
upstream).

[1] http://www.srcf.ucam.org/debian-netbsd/dists/sid-netbsd/main/binary-netbsd-i386/
[2] http://www.srcf.ucam.org/debian-netbsd/source/

-- 
Robert Millan