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

[Chris Johns]

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.

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

Chris