Good evening,
I was looking at implementing the linker elf_i386_haiku emulation in clang /
llvm's lld linker.
A little research showed FreeBSD does something similar (elf_i386_fbsd),
however they
do it *just* to change the ELF OS ABI:
https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L115 ;
(https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L115)
We seem to limit the usage of elf_i386_haiku to bootloader linkflags via:
build/jam/ArchitectureRules: HAIKU_BOOT_LINKFLAGS += -m elf_i386_haiku ;
We don't have our own ELF OSABI, but...
We define elf_i386_haiku as:
https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_i386_haiku.sh
(https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_i386_haiku.sh)
https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_haiku.sh ;
(https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_haiku.sh)
Comparing to the standard elf_i386:
https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_i386.sh ;
(https://git.haiku-os.org/buildtools/tree/binutils/ld/emulparams/elf_i386.sh)
it seems we define a brand new ELF emulation to *just* to adjust the
TEXT_START_ADDR
(and maybe page size) of the loader?
Wouldn't this be better handled by a linker script or something (if we don't
already)?
-- Alex