On Mon, Apr 16, 2018 at 3:53 PM, Amaan Cheval <amaan.che...@gmail.com> wrote:
> 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 > Where did you get your linkcmds? What changes did you make? What does your bsp_specs look like? That could be the __getreent problem. > > ------ > > 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=fd1743d73625bf098fc23af9c06924 > 381f840139;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/4b43095b88e3fed17245a7da91d5b6 > 5a#file-libgomp-config-log-L119-L120 > _______________________________________________ > 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
