[haiku-development] Re: Implement 32 bit userland support for 64 bit Haiku

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 2 May 2018 11:19:25 +0200

Am 01/05/2018 um 17:46 schrieb Jérôme Duval:

I've started to push some patches to help to implement the support of
a 32 bit userland for 64 bit Haiku.

Great!

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

Not beautiful, but we did something like this several times in the past already :-)
With some build system magic, it might even be possible not to commit the binaries this time, which would be nice.

x86 libroot can be made to not use the commpage, using a userland
memcpy.

Since we need it anyway, it might not be worth it to change that, though.

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

Don't we need separate syscalls for 32 bit to correctly set up the parameters? Then those should do any necessary conversions. The current syscalls should not be changed if possible.
One exception could be the "get_{thread|...}_info()" functions, though, as they already get the length of the structure to fill.

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

At the top of my had, I couldn't think of any other options besides changing the args to int64 and doing the conversion in 32 bit userland. Doesn't sound any better to me either, though.

Bye,
   Axel.

Other related posts: