On Tue, Jun 5, 2018 at 4:27 PM, Amaan Cheval <amaan.che...@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 <j...@rtems.org> wrote: > > > > > > On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber > > <sebastian.hu...@embedded-brains.de> wrote: > >> > >> > >> > >> ----- Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval > amaan.che...@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.hu...@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@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
