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

Mon Apr 16 20:53:10 UTC 2018

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.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=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