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

2018-04-17 Thread Joel Sherrill 
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)

2018-04-17 Thread Sebastian Huber 

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)

2018-04-17 Thread Amaan Cheval 
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)

2018-04-16 Thread Joel Sherrill 
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

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

2018-04-16 Thread Amaan Cheval 
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]