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

[Amaan Cheval]

Minor update: I'll work on Chris' suggestion of using FreeBSD's
loader.efi and having that load our static hello.exe - it ought to be
a quicker test that way.
On Sun, Jun 10, 2018 at 9:34 PM Amaan Cheval <amaan.cheval at gmail.com> wrote:
>
> On Sun, Jun 10, 2018 at 12:38 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns <chrisj at rtems.org> wrote:
> >>
> >> On 9/6/18 10:00 am, Joel Sherrill wrote:
> >> > On Thu, Jun 7, 2018, 9:01 PM Chris Johns <chrisj at rtems.org
> >> > <mailto:chrisj at rtems.org>> wrote:
> >> >     > and what
> >> >     > discussions we need to have to decide between the "bundled kernel.so approach"
> >> >     > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"
> >> >     approach. Let
> >> >     > me know!
> >> >     >
> >> >
> >> >     I do not think I can help too much here. I understand the loader.efi+exe
> >> >     solution and it should work because all RTEMS applications we have are
> >> >     statically linked (I am assuming it is here). I have not looked at the details
> >> >     being used with the -fPIC and .so solution so I cannot comment. I do have some
> >> >     concerns the relocatable exe might expose some dark corners and issues in the
> >> >     host tools we have, for example how does GDB find the base address of the image
> >> >     so you can debug it? and is this just working or is it really suppose to work
> >> >     this way?
> >> >
> >> >
> >> > All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and x86.
> >>
> >> I would hope a solution like Deos did provide a seamless way to do this and I
> >> would also hope they support you.
> >
> >
> > I am not using their normal recommended tool setup for users. This is normal
> > RTEMS tools building our test executables. At one point, it was our gdb with
> > their qemu build. They use something like this strictly internally.
> >
> > These executables are statically linked EXCEPT for references to, in
> > the minimum case, two .so's from their environment. I set an argument to
> > ld to ensure all symbols are resolved at link time. Their boot process associates
> > the .so files with the partitions. It is dynamic loading but it is statically configured
> > and not touched after boot.
> >
> > I haven't had any special help from them in this area except figuring out the
> > arguments and linker scripts. When I have access to a build log, I am happy
> > to post the build of hello world for comparison.
> >
> > I have no idea how this compares to UEFI booting except to say that PIC
> > hasn't introduced any tool issues in our GNU tools. libdl may have issues
> > but we aren't using it yet. I can check if the tests pass or are disabled. I
> > don't remember. But that may be illuminating.
> >
> >>
> >>
> >> > We
> >> > have spent a lot of time debugging with gdb attached to qemu.
> >> How does GDB get the relocatable load address to map to the symbol table?
> >>
> >> The libdl code supports the same protocol/design as NetBSD and other systems in
> >> informing GDB about the address of loaded modules. There is a series of symbols
> >> and tables maintained that GDB knows to examine to find the load addresses of
> >> object files.
> >>
> >> > I haven't seen any tools issues yet.
> >>
> >> Yet?  Once the path is settled it will be difficult to change so all I am asking
> >> is the detail be checked and understood. RTEMS does not support shared libraries
> >> the same way Linux or other Unix systems do. I do not understand enough of the
> >> low level and the standards all this is based on to help decide.
> >>
> >> An example of an issue where a relocatable kernel with an unknown load address
> >> creates a problem is libdl. The testsuite uses the 2-pass approach (rtems-syms
> >> --embed) which should be OK however the other approach where the symbol table is
> >> not embedded and built on the host would fail. It is a small issue but it shows
> >> how things can subtly break.
> >
> >
> > I'm not relocating any RTEMS code with Deos. Our code is linked to a static address
> > ranges and invokes Deos methods in the shared libbary.
> >
> > I know this doesn't prove anything concretely about the UEFI exe  but it is the closest
> > example we have. PIC is likely OK. The .so magic could be problematic as it looks
> > like I effectively build a static exe.
>
> The Bsymbolic flag isn't a requirement for this system to work - it
> just helps eliminate the use of the GOT/PLT unnecessarily. Personally,
> I don't think I have the clarity to be able to say whether this is or
> isn't safe - I think the only way to be able to tell will be to
> continue with my work on it and to prove that it either does or
> doesn't, at least in the general case.
>
> What we aim with the hello.so method is the same as you said -
> effectively building a static fully resolved exe, with the difference
> that this _is_ relocatable depending on the UEFI firmware's access and
> availability to memory.
>
> I can't speak to how libdl is affected - but the bit from the ld
> manual about "platforms which support shared libraries" doesn't imply
> libdl / RTEMS needing to support shared libraries to me. What we build
> in this method is hello.so (which includes all of RTEMS' kernel + the
> user application (hello world here)) - the platform that needs to
> support shared libraries then is the UEFI firmware, which from my
> understanding _does_ support it, after we convert the SO to a PE.
>
> My view on next steps is to examine potential side-effects of every
> linker/compiler option we're introducing and summarize and discuss
> them here (starting with the Bsymbolic one, for eg.), and perhaps to
> extend the POC I have that has efi_main->bsp_start working to also
> manage efi_main->boot_card.
> Extending the PoC will be about a week of effort, by my estimate, to
> be hacky - in terms of staying on track, that could be a lot of time
> to waste, so I think I'll leave the decision to you - we're a bit
> ahead, so we may be able to absorb the hit if we change our mind.
>
> P.S. - I think this thread is getting a bit long and this may better
> be discussed on a call so we can settle on a more concrete list of
> what is and isn't resolved from each of our ends. Let me know if you
> see it that way - I'm okay with a benevolent dictator's hammer
> decision too :)
>
> Cheers!
>
> >>
> >>
> >> Chris
> >
> >