<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 16, 2018 at 3:53 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I haven't had much time to continue investigating this specific problem,<br>
but as I suspected, I've been able to work around it for the time being by<br>
simply using gcc 7.2.0 with Newlib 2.5.0 with my patch[1] tacked on to it<br>
(which seems to have fallen through the cracks - I'd appreciate any input<br>
if it needs work!).<br>
<br>
With this workaround, we aren't quite done, but most tests are being linked<br>
with the stub already. Here's a list[2]. Those that aren't, throw the<br>
following error, which I believe should be relatively simple to resolve:<br>
<br>
------<br>
<br>
BSP Testsuite: cdtest: PASS<br>
Making all-am in cdtest<br>
make[3]: Entering directory<br>
'/media/commonhdd/repos/rtems/<wbr>b-no_cpu/x86_64-rtems5/c/no_<wbr>bsp/testsuites/samples/cdtest'<br>
x86_64-rtems5-g++ -O2 -g -ffunction-sections -fdata-sections<br>
  -Wl,--gc-sections<br>
<br>
-B/home/amaan/repos/rtems/b-<wbr>no_cpu/x86_64-rtems5/c/no_bsp/<wbr>lib/libbsp/x86_64/no_bsp<br>
-B/home/amaan/repos/rtems/<wbr>kernel/c/src/lib/libbsp/x86_<wbr>64/no_bsp/startup/<br>
-specs bsp_specs -qrtems -L../../../../../no_bsp/lib<br>
-L/home/amaan/repos/rtems/<wbr>kernel/c/src/lib/libbsp/x86_<wbr>64/shared/startup<br>
-Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -o cdtest.exe init.o<br>
main.o<br>
/media/commonhdd/bin/rtems/5-<wbr>x86_64-gcc72-newlib25/bin/../<wbr>lib/gcc/x86_64-rtems5/7.2.0/..<wbr>/../../../x86_64-rtems5/bin/<wbr>ld:<br>
error: no memory region specified for loadable section `.got.plt'<br>
collect2: error: ld returned 1 exit status<br>
Makefile:667: recipe for target 'cdtest.exe' failed<br>
make[3]: *** [cdtest.exe] Error 1<br></blockquote><div><br></div><div>Where did you get your linkcmds? What changes did you make?</div><div><br></div><div>What does your bsp_specs look like? That could be the __getreent problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
------<br>
<br>
Given the workaround for the issue this thread was opened for, I'm inclined<br>
to not dwell on the __getreent issue for now, but to continue to make<br>
headway towards the stub for the x86_64 port with the older tools.<br>
Does that sound fair to you all? Let me know!<br>
<br>
[1] <a href="https://lists.rtems.org/pipermail/devel/2018-April/020883.html" rel="noreferrer" target="_blank">https://lists.rtems.org/<wbr>pipermail/devel/2018-April/<wbr>020883.html</a><br>
[2] <a href="https://gist.github.com/AmaanC/4cccc6eaf44af29df650221a005bfb01" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>AmaanC/<wbr>4cccc6eaf44af29df650221a005bfb<wbr>01</a><br>
<div class="HOEnZb"><div class="h5">On Tue, Apr 10, 2018 at 2:54 AM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
<br>
> Hi!<br>
<br>
> As part of getting a stub x86_64 stub port to compile using the x86_64<br>
> tools, I've come across the same error as in ticket #3176:<br>
> <a href="https://devel.rtems.org/ticket/3176" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/3176</a><br>
<br>
> _However_ the proposed patches to fix this, which are already in Newlib<br>
> 3.0.0 and the RSB, are part of what cause this error - the following line<br>
> defines the __getreent function:<br>
<br>
> RTEMS_STUB(struct _reent *, __getreent (), { })<br>
<br>
> I don't see how this is compatible with our confdefs.h[1], which also<br>
tries<br>
> to define __getreent[2] and will inevitably cause the multiple<br>
definitions,<br>
> unless we use "-nostdlib".<br>
<br>
> I'm going to continue looking into how we actually use / used __getreent,<br>
> but I believe this problem continues to exist with all tools using<br>
> newlib-3.0.0 now (which RSB uses in the rtems-default.bset) - it makes use<br>
> of our confdefs.h incompatible, which I believe most tests do. I must be<br>
> doing something wrong here, because if this is right, many many builds<br>
> would be failing with the new toolsets when --enable-tests is set.<br>
<br>
> To reproduce:<br>
> - Update RSB (confirm that<br>
> ./rtems/config/tools/rtems-<wbr>gcc-7.3.0-newlib-3.0.0.cfg exists) and rebuild<br>
> your tools for any arch - this should use newlib-3.0.0's libc, which<br>
> defines __getreent.<br>
> - Use the arch's gcc to compile any test that includes confdefs.h or as a<br>
> quick test (slightly quicker than locating crt0.o and analyzing symbols):<br>
<br>
> -> % echo "void __getreent(){}" | i386-rtems5-gcc -xc -v -<br>
> ...<br>
> GNU C11 (GCC) version 7.3.0 20180125 (RTEMS 5, RSB<br>
> c9db1326ef99e3e1267d17d2c7e5e5<wbr>1a48d1be2a, Newlib 3.0.0) (i386-rtems5)<br>
> ....<br>
> /tmp/cc90vvoP.o: In function `__getreent':<br>
> :(.text+0x0): multiple definition of `__getreent'<br>
<br>
> ---------------<br>
> Next steps:<br>
> - Figure out how __getreent is actually meant to be used based on the<br>
> confdefs setup - reentrancy seems relevant to interrupts, so I imagine<br>
> RTEMS should be able to maintain control entirely. Is that right? Should<br>
> __getreent be left as a dynamically resolved symbol up until the RTEMS<br>
> executive can resolve it (if that's even an option)?<br>
<br>
> (Possibly tangential:<br>
> I do see that newlib needs the definition of __getreent for __errno[3][4].<br>
> If I remove the definition from newlib, gcc fails to even compile in<br>
> bootstrapping gcc, the compiler throws an undefined reference to<br>
> __getreent[5], understandably, when trying to compile libgomp, since there<br>
> are missing references within the stdlib. I imagine some linker tricks<br>
> could let me pull it off, but I'm not _quite_ sure I understand all the<br>
> actors in this complex dance yet.)<br>
<br>
> P.S. - Sorry about the length of the email! I tend to put more information<br>
> in rather, but if you think I should keep them more concise and to the<br>
> point, let me know, please! Thanks!<br>
<br>
> [1] <a href="https://sourceware.org/ml/newlib/2017/msg01020.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/<wbr>newlib/2017/msg01020.html</a><br>
> [2] <a href="https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs.h#n2266" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/<wbr>tree/cpukit/include/rtems/<wbr>confdefs.h#n2266</a><br>
> [3]<br>
<br>
<a href="https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/errno/errno.c;h=fd1743d73625bf098fc23af9c06924381f840139;hb=HEAD#l13" rel="noreferrer" target="_blank">https://sourceware.org/git/<wbr>gitweb.cgi?p=newlib-cygwin.<wbr>git;a=blob;f=newlib/libc/<wbr>errno/errno.c;h=<wbr>fd1743d73625bf098fc23af9c06924<wbr>381f840139;hb=HEAD#l13</a><br>
> [4]<br>
<br>
<a href="https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/reent.h;h=6e55e1c1fa760c4090a1f9cca8c9f83ae68065f9;hb=HEAD#l825" rel="noreferrer" target="_blank">https://sourceware.org/git/<wbr>gitweb.cgi?p=newlib-cygwin.<wbr>git;a=blob;f=newlib/libc/<wbr>include/sys/reent.h;h=<wbr>6e55e1c1fa760c4090a1f9cca8c9f8<wbr>3ae68065f9;hb=HEAD#l825</a><br>
> [5]<br>
<br>
<a href="https://gist.github.com/AmaanC/4b43095b88e3fed17245a7da91d5b65a#file-libgomp-config-log-L119-L120" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>AmaanC/<wbr>4b43095b88e3fed17245a7da91d5b6<wbr>5a#file-libgomp-config-log-<wbr>L119-L120</a><br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>