This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Should __data_end__ and __data_start__ be the same?

I'm looking at the output of nm on my ELF file:

20002004 00000002 d heart_rate	/path/to/Debug/../src/ble.c:132
.
.
.
200028ac D __data_end__
200028ac D __data_start__
200028ac d __fini_array_end
200028ac d __fini_array_start
200028ac d __init_array_end
200028ac d __init_array_start
200028ac d __preinit_array_end
200028ac d __preinit_array_start

Based on gcc_nrf51_common.ld, I would expect __data_start__ and __data_end__ to bound my initialized data. The problem I'm having is that my initialized globals don't seem to get initialized. i.e. heart_rate doesn't get the value 70 like it should (instead it gets different values):

uint16_t heart_rate = 70;

The d in front of heart_rate indicates that it should be in the initialized data section--so shouldn't __data_end__ expand to accommodate at least the heart_rate variable?

Somehow, it looks to me like the linker script is being run twice. This is an excerpt from the .map file:

 .data           0x0000000020002000      0x438 load address 0x0000000000021180
                0x0000000020002000                __data_start__ = .
 *(vtable)
 *(.data*)
 .data.m_conn_handle
                0x0000000020002000        0x2 ./src/ble.o
 .data.m_rr_interval_enabled
                0x0000000020002002        0x1 ./src/ble.o
 *fill*         0x0000000020002003        0x1 
 .data.heart_rate
                0x0000000020002004        0x2 ./src/ble.o
 .data.rr_interval
                0x0000000020002006        0x2 ./src/ble.o
 .data.m_transfer_completed
                0x0000000020002008        0x1 ./src/cc1101.o
 *fill*         0x0000000020002009        0x7 
 .data.impure_data
                0x0000000020002010      0x428 /usr/local/gcc-arm-none-eabi-4_8-2014q3/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv6-m/libc.a(lib_a-impure.o)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__preinit_array_start, .)
 *(.preinit_array)
                0x0000000020002438                PROVIDE (__preinit_array_end, .)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__init_array_start, .)
 *(SORT(.init_array.*))
 *(.init_array)
                0x0000000020002438                PROVIDE (__init_array_end, .)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__fini_array_start, .)
 *(SORT(.fini_array.*))
 *(.fini_array)
                0x0000000020002438                PROVIDE (__fini_array_end, .)
 *(.jcr)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                __data_end__ = .
                0x0000000020002438                __data_start__ = .
 *(vtable)
 *(.data*)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__preinit_array_start, .)
 *(.preinit_array)
                0x0000000020002438                PROVIDE (__preinit_array_end, .)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__init_array_start, .)
 *(SORT(.init_array.*))
 *(.init_array)
                0x0000000020002438                PROVIDE (__init_array_end, .)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                PROVIDE (__fini_array_start, .)
 *(SORT(.fini_array.*))
 *(.fini_array)
                0x0000000020002438                PROVIDE (__fini_array_end, .)
 *(.jcr)
                0x0000000020002438                . = ALIGN (0x4)
                0x0000000020002438                __data_end__ = .

Notice that __data_start__ is correct at first. Then it's redefined to what __data_end__ ends up being.

Parents
  • It turns out I was running the linker script twice. gcc_nrf51_s110_xxac.ld has

    INCLUDE "gcc_nrf51_common.ld"
    

    However, I had told ld to use both gcc_nrf51_s110_xxac.ld and gcc_nrf51_common.ld on the command line (Actually via Project Properties->C/C++ Build->Settings->Cross ARM C Linker->General->Script files in Eclipse with the GNU ARM Eclipse Plug-in).

    Because the gcc_nrf51_common.ld got run twice, it redefined __data_start__ to the same as __data_end__.

    So the answer is: __data_end__ should not equal __data_start__, and don't put both linker scripts into the Eclipse project properties--just the gcc_nrf51_s110_xxac.ld script.

Reply
  • It turns out I was running the linker script twice. gcc_nrf51_s110_xxac.ld has

    INCLUDE "gcc_nrf51_common.ld"
    

    However, I had told ld to use both gcc_nrf51_s110_xxac.ld and gcc_nrf51_common.ld on the command line (Actually via Project Properties->C/C++ Build->Settings->Cross ARM C Linker->General->Script files in Eclipse with the GNU ARM Eclipse Plug-in).

    Because the gcc_nrf51_common.ld got run twice, it redefined __data_start__ to the same as __data_end__.

    So the answer is: __data_end__ should not equal __data_start__, and don't put both linker scripts into the Eclipse project properties--just the gcc_nrf51_s110_xxac.ld script.

Children
No Data
Related