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

[Chris Johns]

On 6/6/18 5:22 pm, Amaan Cheval wrote:
> 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.
> 

Do we need to port it or can we use a released version from an installed FreeBSD?

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

I was just wondering if a temporary short cut can be taken so we do not spend
all our time on booting an image.

Chris