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

[Amaan Cheval]

On Sat, Jun 9, 2018 at 5:26 AM Chris Johns <chrisj at rtems.org> wrote:
>
> 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?

No, it was only the dynamic/shared library "hello.so" (that I attached
in an earlier email, in case you want to play with it yourself).

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

That's a good point. I see this article which seems to me like it _is_
a fair concern, especially in the case of something as complex as
RTEMS.
https://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects

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

If we go with the static approach (loader.efi+hello.exe), my guess is
yes, that ought to work in some sense - long mode code would run, but
if we expect the loader to configure hardware in a specific way or
leave information (eg. memory available) in specific places, we'd be
at FreeBSD's loader.efi's mercy.

Just as a reminder - if you all aren't truly satisfied of either of
these approaches, we _do_ have the option to not use gnu-efi too.
Namely, the ASM generated header and EDK2 (which looks too complicated
IMO for what we may need).

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

Thanks for the offer! I'll reach out if I do - so far it's been
manageable, it's just that I can't speak knowledgeably with regards to
the build system yet.

>
> Chris