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

[Amaan Cheval]

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)

>
>> 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. Supporting Multiboot
too will involve adding some code to move to 64-bit mode before
actually calling into the generalized 64-bit mode code.

>
> 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!

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.

>
> Chris