[GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 6/6/18 5:06 pm, Amaan Cheval wrote:
> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns <chrisj at rtems.org> wrote:
>> On 4/6/18 7:49 pm, Amaan Cheval wrote:
>>> Please let me know if that approach doesn't make sense - given that
>>> there is no dynamic loader in the RTEMS kernel as far as I know,
>>
>> There is a dynamic loader in RTEMS called libdl. It is not based around the ELF
>> standard loader used for shared libraries and will not be. GOT and PLT do not
>> add value to RTEMS because we do not have an active virtual address space with
>> paging.
>>
>> The libdl code is currently supported with the i386 static builds. I would hope
>> this would continue to be supported without major refactoring of that code.
>> There are tests in the testsuite under libtests.
> 
> Hm, so libdl can load static ELFs and handle those relocations itself?
> In that case we could go the "FreeBSD" way more easily as I outlined
> earlier; a loader UEFI application image (loader.efi) + the
> application image to be found on the filesystem and loaded through
> libdl, which we somehow call through loader.efi.
> 
> loader.efi -> libdl -> hello.exe (static executable ELF now)
> 

libdl is not designed to do this and do not think it could be made too. It needs
a full RTEMS kernel located to run.

>>
>>> what
>>> we really want _is_ a static file, but for it to be a relocatable PE,
>>> we need to convince GCC to spit out a relocatable but fully resolved
>>> shared library.
>>
>> It is not clear to me yet making the kernel relocatable is free of other
>> possible issues. I will need to find time to review all the low level parts here
>> and my time is currently limited.
>>
>> Does this UEFI work effect the score context switcher, interrupts, etc? If is
>> does we will need to resolve what happens and if not should we consider leaving
>> it if we can?
> 
> It affects it in the sense that it's all compiled with fPIC, yes. It
> needs to be if we're bundling it all together (creating hello.efi,
> which includes the UEFI boot code, all of RTEMS, and the user app).
> 
>> For example can iPXE chain load a multiboot image?
> 
> Yes, we could just use Multiboot too. One thing to note, though -
> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
> firmware will load is into 64-bit protected mode.

Ah OK this is a good point and boards like a Minnow have a 32bit or 64bit BIOS
or what ever it is called on those boards so this may not work.

> Supporting Multiboot
> too will involve adding some code to move to 64-bit mode before
> actually calling into the generalized 64-bit mode code.

Can it be used as a step towards another solution?

> 
>>
>> Sorry to have disappeared for a period at a critical time in this discussion, it
>> was beyond my control.
> 
> No worries! Hope everything's okay!
> 

Thanks and yes.

> I'll look into libdl further in the meantime and continue to polish up
> the stub to reflect more of the x64 features, while we figure out our
> boot direction.

Great. I hope to be back full time next week and I can have a look.

Chris