multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)

Mon Apr 16 21:44:46 UTC 2018

On Mon, Apr 16, 2018 at 3:53 PM, Amaan Cheval <amaan.cheval at 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.cheval at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180416/b946351a/attachment-0001.html>