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

[Amaan Cheval]

Chris, I've blogged a summary of the 2 approaches we can take in
integrating gnu-efi in case you missed the discussions earlier, btw.
The FreeBSD approach isn't as fleshed out, but I'll let you all know
what I find there.

https://blog.whatthedude.com/post/gnu-efi-kernel-so/

On Wed, Jun 6, 2018 at 2:30 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> I don't know yet, but I'll look into it. I'll pause the "hello.efi" approach
> work until we settle on a direction, yes? For now, primarily improving the
> stub, looking into the FreeBSD ld-elf.so, etc. Sound good?
>
> On Wed, Jun 6, 2018, 1:01 PM Chris Johns <chrisj at rtems.org> wrote:
>>
>> 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