[haiku-development] Re: FatELF Implementation
- From: Landon J Fuller <landonf@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 28 Nov 2012 11:41:32 -0500
On Nov 28, 2012, at 8:06 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 11/27/2012 01:20 AM, Landon J Fuller wrote:
>> I set aside my Thanksgiving vacation to work on FatELF (fitting for the
>> season?), and I have haiku_loader, kernel, and runtime_loader changes ready
>> for review. This was a great introduction to the Haiku code base, and I hope
>> my code will measure up to the existing level of quality. While I made every
>> effort to conform to style standards, while also remaining consistent with
>> surrounding style, I'm sure I might have missed something. If so, I
>> apologize, and I'll be happy to clean it up.
>>
>> With these changes, one can load/execute multi-architecture kernels,
>> kernel-addons, and userspace executables and libraries. For example:
>> ~> ~/fatelf-haiku/fatelf-glue hello hello-i386 hello-x86-64
>> ~> ./hello
>> Hello, World!\n
>
> Nice!
>
>> This only encompasses the OS work necessary to execute fat binaries. I plan
>> to tackle next:
>> - Developer tools, including gcc and gdb. My goal is that one can run
>> simply run:
>> gcc -arch x86 -arch x86_64 -arch x86-gcc2 hello.c -o hello
>> - A combined x86-64/x86/(x86-gcc2) distribution.
>>
>> The latter goal is a large one, and will also involve implementing 32-bit
>> syscall compatibility in the x86-64 port, unless someone else beats me to it.
>
> There's a bit more to it than just syscall compatibility. You'll also need to
> be able to load a 32 bit runtime loader, support 32 bit thread entries and
> signal handling and generally a 32 bit userland. I haven't looked into what
> exactly the latter entails, but I think you'll have to additionally do 32 bit
> paging for 32 bit teams, which might require a bit of VM hacking.
Thanks. I looked into the runtime loader in the context of FatELF; with the
FatELF patches, the kernel is sniffing out the best available architecture in
the target binary, and then loading the 'best' abi-compatible runtime loader
binary it can find (eg, it in theory could use am armv7 runtime_loader with an
armv6-hf binary). A similar approach could be used without FatELF, of course.
For the remainder, I'll have to dig in more once I'm a bit farther along with
the tooling, but these initial pointers are a big help.
Cheers,
Landon
Other related posts:
