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

[Amaan Cheval]

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