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

[Joel Sherrill]

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.

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180609/1245cd60/attachment-0002.html>