Hi,
I've started to push some patches to help to implement the support of
a 32 bit userland for 64 bit Haiku.
https://review.haiku-os.org/#/c/130/
https://review.haiku-os.org/#/c/133/
Adrien asked for a few details on how this would go. Here they are:
* support for gcc5 x86 binaries is the goal I expect to achieve: for
example run the x86 java binaries.
* a x86 runtime_loader is needed because runtime_loader runs in the
target process mode.
* the kernel needs to be able to identify an elf32 binary, and choose
the respective runtime_loader: this would be probably hardcoded.
* x86 userland needs its own commpage: the commpage indexes are arch
specific. the plan is to add a "compat" commpage, used by the 32-bit
support code in the kernel.
* the kernel builds copies of userland code, which be copied in the
commpage, memcpy, syscall trampoline, signal exec. This is especially
difficult to support because the linker doesn't seem to like combining
32-bit code in a 64-bit binary. The idea here is simply producing
precompiled data and linking it in the kernel, not beautiful right.
x86 libroot can be made to not use the commpage, using a userland
memcpy.
* handling 32-bit syscalls: in each syscall, we check whether the
thread runs in compatibility mode, then create the 64-bit structures
from the 32-bit ones.
* the proposal is to use the _COMPAT_MODE macro to enable to
compatibility mode:
+
+ if x86 in $(HAIKU_ARCHS[2-]) || x86_gcc2 in
$(HAIKU_ARCHS[2-]) {
+ Echo "Enable kernel ia32 compatibility" ;
+ HAIKU_KERNEL_DEFINES += _COMPAT_MODE ;
+ HAIKU_KERNEL_COMPAT_MODE = 1 ;
+ }
* the runtime_loader would get elf32 detected for the primary arch and
elf64 detected for the secondary arch.
* the kernel needs to handle the userArgs and userEnv for the target
arch. I tried a conversion from 64-bit to 32-bit, this works but is
very ugly. Ideas welcome.
Feel free to comment here, or on the changes that will go in the
review process.
Bye,
Jérôme
