[En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers

[Ulrich Prinz]

Hi Ole,

I never had this kind of problem, but I never used 64 bit variables...

But... I compared the local nut/os version for cortexM3 with the
sourceforge one and the only bigger difference is the double -L
parameter for the linker.
You remember the problem I have that building a simple uart example
results in 14k code instead of 6k or less in older versions?
I guess (but didn't test, cause lack of time) that this might be the problem.

Can you test again with
LDFLAGS = ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs'
instead of
LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' ... -L'path_to_libs'

It's just a feeling...
Linker might test the first search path only and include stdlibs on
failing result even the nutos libs exist in the second one.

If it is still needed to have the linker scripts in search path, we
could reorder the parameters and test again:
LDFLAGS = ... -L'path_to_libs' ... -L'path/to/linker/' -T'ldscript.ld'

Ulrich

Am 6. Februar 2012 23:19 schrieb Ole Reinhardt <ole.reinhardt at embedded-it.de>:
> Hi all,
>
> in one special situation I need to use a 64bit devision on a Cortex M3.
> Compiling works fine, but the linker trows the following problems:
>
> arm-eCross-eabi-gcc test.o -mcpu=cortex-m3 -mthumb -mlittle-endian
> -D__CORTEX__ -nostartfiles
> -L/home/ole/work/Streamit/NutOS_M3N/nut/arch/cm3/ldscripts
> -Tlpc1778_flash.ld -Wl,-Map=uart.map,--cref,--gc-sections
> -L/home/ole/work/Streamit/nut-build-lpc177x_8x/lib
> -Wl,--start-group /home/ole/work/Streamit/nut-build-lpc177x_8x/lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch   -Wl,--end-group -o uart.elf
> /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort':
> /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../src/newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
> /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r':
> /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
> /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r':
> /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
> /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
> /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'
> collect2: ld returned 1 exit status
>
>
> The program itself looks like this:
>
> #include <inttypes.h>
> int main()
> {
>    uint64_t *a,b;
>    volatile uint64_t c;
>    a = 0xaa000aa00;
>
>    b= 0xaa00aa0000550055;
>
>    c = b/(*a);
>
>    if (c < 100) return 1;
>
>    while(1);
>    return 0;
> }
>
> Btw: defining a as pointer is just a trick to trick the optimizer (which
> eliminates constant calculations)
>
>
> Beside the above problem the linker complained about overlapping
> sections .data with (implicit?) segments ARM.extab ad ARN.exidx
>
> I fixed this by adding the requested segments (see part of the
> lpc17xx_flash.ld linker script below):
>
>   .text :
>    {
>        . = ALIGN(4);
>        _svect = .;
>        KEEP(*(.isr_vector))
>        _evect = .;
>        *(.text .text.* .gnu.linkonce.t.*)
>        *(.rodata .rodata* .gnu.linkonce.r.*)
>        *(.glue_7t)
>        *(.glue_7)
>        *(.gcc_except_table)
>            . = ALIGN(4);
> /*        _etext = .;*/
>    } > FLASH0
>
>    /* for exception handling/unwind - some Newlib functions (in common
> with C++ and STDC++) use this. */
>
>    .ARM.extab :
>    {
>        *(.ARM.extab* .gnu.linkonce.armextab.*)
>    } >  FLASH0
>
>    __exidx_start = .;
>    .ARM.exidx :
>    {
>        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
>    } >  FLASH0
>    __exidx_end = .;
>
>    _etext = .;
>
>    .vtable (NOLOAD):
>    {
>        . = ALIGN(4);
>            _vtable = .;
>            *(.vtable*)
>        . = ALIGN(4);
>            _evtable = .;
>    } > SRAM0
>
>
> Does anybody has an idea of what is going wrong here?
>
> Best regards,
>
> Ole Reinhardt
>
> --
>
> Thermotemp GmbH, Embedded-IT
>
> Embedded Hard-/ Software and Open Source Development,
> Integration and Consulting
>
> http://www.embedded-it.de
>
> Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
> tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
>
> Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
> Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
> Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
> Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion