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

[Amaan Cheval]

On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns <chrisj at rtems.org> wrote:
> On 08/06/2018 01:50, Amaan Cheval wrote:
>>
>> Joel, Chris, I'd appreciate guidance on what I ought to work on next
>
> I would like to see the focus on the kernel context switcher, FPU support, and
> then interrupts so we have the basic drivers we need like a tick interrupt running.
>
> This assumes the loader issues we have not resolved do not effect this work.
>

They do affect it to a certain extent - I'd be working semi-blind
since without tying the loose ends required to boot, I wouldn't be
able to test the implementations of the areas you mentioned. I'm not
at that point yet, but I suspect I will be within a week or so, so the
sooner we determine the approach required for booting, the better.

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

Well, these images won't simply _run_ through GDB, no - but here's
some stuff that may be helpful to see:
https://gist.github.com/AmaanC/4e1aaa2cbdda974b93c5a3e1eac5318a

One concern of yours was the unnecessary addition of the GOT/PLT.
Thankfully, through options like -Bsymbolic, we can circumvent the
GOT/PLT for all symbols which have already been resolved (as you'll
see happens for "InitializeLib", "Print", "boot_card", etc. (boot_card
because this is from my WIP version trying to get boot_card to work
with this method too)).

I'm definitely concerned, but having looked at it more, I can't find
anything specific that would genuinely cause problems besides
unresolved symbols - we could have a build-time check for them,
though, failing the build when that's the case (-Wl,-z,defs does it).

So for next steps, I guess you'll be looking into how the use of -fPIC
may affect us, and we can work on addressing those concerns, right? I
personally preferred the static build approach too, since that way we
can "plug" loaders in:
- loader.efi for UEFI firmware
- multiboot header + 32 to 64 bit mode code for Multiboot

That's a slight oversimplification since (1) needs to be packaged on
the filesystem with the static hello.exe and (2) needs to be linked in
with it, but I think the build system retains more of its separations
from the boot method this way (though I can't be sure given my
relatively naive view of RTEMS + autotools).

>
> Chris