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

[Chris Johns]

On 9/6/18 2:39 am, Amaan Cheval wrote:
> 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.

OK.

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

Interesting and thanks. Is this with QEMU?

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

The -Bsymbolic option is an example of my concern and stepping into a dark
corner. It could also be my lack of understanding. Yes it works but is that
always going to be the case? For example the GNU ld manual states:

 "This option is only meaningful on ELF platforms which support shared
  libraries and position independent executables."

and technically we do not support shared libraries so is this usage a normal use
case? I do not know. Also Oracle says the option is somewhat historic:

 https://docs.oracle.com/cd/E19957-01/806-0641/chapter4-16/index.html

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

If loader.efi+exe avoids this then it makes sense to me to do so. The less we
bend or stretch the more stable the support will be over time.

> 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 do not know because I do not know risks.

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

Agreed.

> That's a slight oversimplification since (1) needs to be packaged on
> the filesystem with the static hello.exe

Yes this is a good point, then again this target is a bit different to other
targets. Users of PCs and similar hardware are use to boot loaders and managing
them plus handling the media needed. I do not think we will ever create a
bootable within an RTEMS build.

Could I install FreeBSD, load an RTEMS kernel onto the root directory and then
boot it with the standard FreeBSD loader.efi chain?

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

I can help here if you need it.

Chris