v850 tool chain broken with -fdata-sections

[Joel Sherrill]

On Wed, Nov 7, 2018 at 7:57 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> I noticed a problem with the latest v850 tool chain which uses
> -fdata-sections for Newlib:
>
> gmake[1]: Entering directory
> '/build/git-build/b-all-v850-5/v850-rtems5/c/v850e1sim/testsuites/samples'
> v850-rtems5-gcc  -mv850e1 -O2 -g -ffunction-sections -fdata-sections
> -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -Wl,-Map,map.txt
> -B./../../lib/libbsp/v850/gdbv850sim
> -B/home/EB/sebastian_h/git-rtems-5/bsps/v850/gdbv850sim/start -specs
> bsp_specs -qrtems -L./../../cpukit
> -L/home/EB/sebastian_h/git-rtems-5/bsps/v850/shared/start
> -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections
> -o base_sp.exe base_sp/base_sp-init.o base_sp/base_sp-apptask.o
> ./../../lib/libbsp/v850/gdbv850sim/librtemsbsp.a
> ./../../cpukit/librtemscpu.a
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/bin/ld:
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/lib/v850e/libc.a(lib_a-exit.o):
>
> in function `exit':
> /scratch/git-rtems-source-builder/rtems/build/v850-rtems5-gcc-7.3.0-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1/build/v850-rtems5/v850e/newlib/libc/stdlib/../../../../../../gcc-7.3.0/newlib/libc/stdlib/exit.c:62:(.text.exit+0xe):
>
> relocation truncated to fit: R_V810_GPWLO_1 against symbol
> `_global_impure_ptr' defined in .rodata._global_impure_ptr section in
>
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/lib/v850e/libc.a(lib_a-impure.o)
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/bin/ld:
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/lib/v850e/libc.a(lib_a-reent.o):
>
> in function `reclaim_reent':
> /scratch/git-rtems-source-builder/rtems/build/v850-rtems5-gcc-7.3.0-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1/build/v850-rtems5/v850e/newlib/libc/reent/../../../../../../gcc-7.3.0/newlib/libc/reent/reent.c:46:(.text._reclaim_reent+0x6):
>
> relocation truncated to fit: R_V810_GPWLO_1 against symbol `_impure_ptr'
> defined in .data._impure_ptr section in
>
> /build/rtems/5/lib/gcc/v850-rtems5/7.3.0/../../../../v850-rtems5/lib/v850e/libc.a(lib_a-impure.o)
> collect2: error: ld returned 1 exit status
> gmake[1]: *** [Makefile:733: base_sp.exe] Error 1
> gmake[1]: Leaving directory
> '/build/git-build/b-all-v850-5/v850-rtems5/c/v850e1sim/testsuites/samples'
>
> I guess this is somehow related to this definition in Newlib:
>
> #ifdef __v850
> #define __ATTRIBUTE_IMPURE_PTR__ __attribute__((__sda__))
> #endif
>
> User of _global_impure_ptr thinks it is in the small-data area, but
> definition is elsewhere.
>

The small data areas are usually finite resources. I don't like
infrastructure putting
burden on it. Would it make sense to not put this is the sda for RTEMS?

--joel

>
> --
> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> 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/20181107/22f9ebc0/attachment-0001.html>