Hi, nice to see the irc discussion with Adrien had some further response.
On Tue, May 1, 2018 at 5:46 PM, Jérôme Duval <jerome.duval@xxxxxxxxx> wrote:
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.
