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

[Joel Sherrill]

On Tue, Jun 5, 2018 at 4:27 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:

> Hi! Thanks for the guidance, both of you! I think we're quite close
> now to integrating gnu-efi in and finally having the stub port boot as
> a UEFI application image. All the test exe's generated on my local
> tree are now dynamic libraries, so both Newlib and crtbeginS/crtendS
> issues have been resolved (see point 2 below for the relevant WIP
> patches).
>
> Here's what I've done:
>
> - Updated amd64.cfg as Joel instructed earlier - here I put "-shared"
> in LDFLAGS instead of CPU_CFLAGS because of configure trying to use
> CPU_CFLAGS in general, running into unresolved symbols coming from
> GCC's stub crt0.c, and falling down. Putting it in LDFLAGS lets me
> work around this, but I'd appreciate a thumbs-up on this being okay:
>
> https://github.com/AmaanC/rtems-gsoc18/commit/
> 547ef85a7f176046b2cb06a34b1e312c4986e97f#diff-
> c64f46c71f828120e08bc4c8667f0525R18
>
>
This looks like the other BSPs.


> - Updated GCC as follows, building on top of Joel's WIP patch to
> minimize bsp_specs:
>
> https://github.com/AmaanC/gcc/pull/1


This doesn't have much code to review either. I think it is OK.


>
>
> I made it a PR on my fork so viewing it commit-wise or as a whole diff
> is easier for you to review. I'll look into how to make and use
> multilib variants next.
>
> Let me know what you think (about the LDFLAGS workaround, and the
> approach for the GCC patch so far).
>

The amd64.cfg file looks like I would expect. Not really a hack.

>
> On Mon, Jun 4, 2018 at 6:42 PM, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber
> > <sebastian.huber at embedded-brains.de> wrote:
> >>
> >>
> >>
> >> ----- Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval
> amaan.cheval at gmail.com:
> >>
> >> > That's a good idea. That way based on the multilib variant, Newlib
> would
> >> > be
> >> > compiled using fPIC, yes?
> >>
> >> Yes.
> >
> >
> > This would be desirable for the i386 as well. Having the RTEMS libraries
> as
> > dynamic libraries would be more natural under Deos.
> >
> > Just a statement. Not a requirement on the GSoC project.
> >>
> >>
> >> >
> >> > Then I could simply figure out how to solve the crtbegin and crtend
> >> > dilemma
> >> > (which I believe should be easier), and use those to have a
> >> > dynamic/shared
> >> > RTEMS kernel + user application.
> >>
> >> These files will be compiled with -fPIC as well.
> >
> >
> >
> >>
> >>
> >> >
> >> > If that sounds right, I'll look into that first. Not familiar with the
> >> > GCC
> >> > source yet, but it should be doable.
> >>
> >> Sorry, I have no idea how the x86_64 configuration of GCC works for
> RTEMS.
> >>
> >> >
> >> >
> >> > On Mon, Jun 4, 2018, 3:43 PM Sebastian Huber <
> >> > sebastian.huber at embedded-brains.de> wrote:
> >> >
> >> >> Hello Amaan,
> >> >>
> >> >> can't you add a new multilib variant which includes -fPIC to the GCC
> >> >> configuration for RTEMS?
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180605/fb6339ca/attachment.html>