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

[Amaan Cheval]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180606/1bc62b12/attachment-0001.html>