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