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

[Amaan Cheval]

On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns <chrisj at rtems.org> wrote:
> 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.

Ah, I see. In that case porting FreeBSD's ELF loader is the only
viable option in this direction, I believe, since the ELF to be loaded
would be the RTEMS kernel+the user app.

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

Not sure what you mean - like if it would be useful anywhere outside
of the Multiboot work? If so, no, likely not, unless we also want
legacy BIOS support eventually, in which case it could be part of the
real mode->protected mode->long mode transition chain, but that's
unlikely :P

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