Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
On Tue, Apr 17, 2018 at 3:35 AM, Amaan Cheval wrote: > Great tips, thank you for the help! > Updating the bsp_specs to replace startfile with crtbegin.o did let me get > past the the __getreent problems. It seems like I'll need to learn much > more about linker scripts and the GCC spec syntax than I currently know to > do this right - I've currently only worked around issues in those regards > with guesses / copying blindly from other archs and testing. > startfile needs to be the equivalent of crt0. In RTEMS parlance, this is usually start.o and it does thing like setup the stack, required registers, etc. > > I'll read the scripts used for other architectures and the following > resources in the meantime to better understand how this ought to be > structured to be correct. Let me know if you have any other resources you'd > recommend! > > - https://dev.gentoo.org/~vapier/crt.txt > - https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html > - https://docs.rtems.org/branches/master/bsp-howto/linker_script.html > - > https://docs.rtems.org/branches/master/bsp-howto/ > miscellanous_support.html#gcc-compiler-specifications-file > - > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-example.html > On Tue, Apr 17, 2018 at 12:13 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > Hello, > > > you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib > > provides a crt0.o file which contains a bunch of global symbols suitable > > enough to make the GCC link-time configure tests happy. This file must > > never be used for a real RTEMS application. The default startfile of GCC > > (which is this Newlib ctr0.o) must be overruled. This is usually done > > be the bsp_specs. See also > > > https://lists.rtems.org/pipermail/devel/2017-December/019780.html > > > -- > > Sebastian Huber, embedded brains GmbH > > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > > Phone : +49 89 189 47 41-16 > > Fax : +49 89 189 47 41-09 > > E-Mail : sebastian.hu...@embedded-brains.de > > PGP : Public key available on request. > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ > 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
Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
On 17/04/18 10:35, Amaan Cheval wrote: - https://docs.rtems.org/branches/master/bsp-howto/linker_script.html You have to be careful with the BSP guilde. It is a bit out of date. For a reference linker command file I would use this: https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base Use this to get the default linker command file: x86_64-rtems5-ld --verbose -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
Great tips, thank you for the help! Updating the bsp_specs to replace startfile with crtbegin.o did let me get past the the __getreent problems. It seems like I'll need to learn much more about linker scripts and the GCC spec syntax than I currently know to do this right - I've currently only worked around issues in those regards with guesses / copying blindly from other archs and testing. I'll read the scripts used for other architectures and the following resources in the meantime to better understand how this ought to be structured to be correct. Let me know if you have any other resources you'd recommend! - https://dev.gentoo.org/~vapier/crt.txt - https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html - https://docs.rtems.org/branches/master/bsp-howto/linker_script.html - https://docs.rtems.org/branches/master/bsp-howto/miscellanous_support.html#gcc-compiler-specifications-file - https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-example.html On Tue, Apr 17, 2018 at 12:13 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib > provides a crt0.o file which contains a bunch of global symbols suitable > enough to make the GCC link-time configure tests happy. This file must > never be used for a real RTEMS application. The default startfile of GCC > (which is this Newlib ctr0.o) must be overruled. This is usually done > be the bsp_specs. See also > https://lists.rtems.org/pipermail/devel/2017-December/019780.html > -- > Sebastian Huber, embedded brains GmbH > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
Hello, you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib provides a crt0.o file which contains a bunch of global symbols suitable enough to make the GCC link-time configure tests happy. This file must never be used for a real RTEMS application. The default startfile of GCC (which is this Newlib ctr0.o) must be overruled. This is usually done be the bsp_specs. See also https://lists.rtems.org/pipermail/devel/2017-December/019780.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
On Mon, Apr 16, 2018 at 3:53 PM, Amaan Cheval 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/46eaf44af29df650221a005bfb01 > On Tue, Apr 10, 2018 at 2:54 AM Amaan Cheval > 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 > inform
Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
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/46eaf44af29df650221a005bfb01 On Tue, Apr 10, 2018 at 2:54 AM Amaan Cheval 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
multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)
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