ld script expression - wrong result when mixing constants & symbols

Adding RAM_START_ADDRESS to . is highly suspicious to me. Current point is already within ram scope, adding it again to ram start address does not make sense.

Hi Joey - thanks a lot for your reply.

I can appreciate your concern about the calculation but ultimately the result of this calculation:

 . += (RAM_START_ADDRESS + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE - _end);

should be (expanding and parenthesizing as it appears in the map file):

. = . + ((((0x20000000 + 0x10000) - 0x1000) - 0x2000) - 0x200017b0)

or

. = . + 0xb850

But it's not when _end is used but IS when the literal constant value of _end (0x200017b0) is used.

I can't see any obvious risk of underflow or type incompatibility issues here.

Oh - and I should have added that there is no problem when I use a different/older toolchain - Mentor Sourcery CodeBench Lite 2010q1-188 which uses ld 2.19.51.20090709.

Any further ideas?

Thanks again.

BTW - I also tried rearranging the expression - e.g.:

 . += (_end - RAM_START_ADDRESS + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE);

and parenthesizing it to make the precedence explicit but still no difference.

As long as I use the _end symbol (or any of the synonyms) the value calculated seems completely wrong and, so far, inexplicable.

:-|

IMHO you are calculating two different objects (_end - RAM_START_ADDRESS) from the view of linker script. The _end is a variable defined in C source code while the RAM_START_ADDRESS is linker script own variable. I don't think current linker is smart enough to distinguish them. Perhaps this could be a new feature to linker.

Thanks Terry but I don't think that you are correct:

(1) _end is not a C variable - it is a ld script defined symbol same as the others (although the others are global symbols)

(2) This worked fine in the earlier version of ld (CodeSourcery) that I mentioned above

Curiously I found that this works properly but I still don't understand why it works or why the change is necessary:

 . += (ABSOLUTE(RAM_START_ADDRESS) + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE - _end);

Ideally I'd still like to understand this and why the change since the earlier version of ld...

This also works:

  .heap :
  {
    __heap_start__ = .;
    . = ORIGIN(ram) + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE;
    . = ALIGN(0x10);
    _eheap = .;
  } >ram

Hi TM,

I'm not very familiar with linker script but from what I understood of the documentation your _end symbol is defined relative to the start of the .bss section (it evaluates as an offset from the beginning of the .bss section) but you use it as if it were the absolute address where it'll be loaded in memory. I'm a bit surprised that taking the absolute value of RAM_START_ADDRESS works but maybe, despite what the syntax suggest, it takes the absolute of everything on the line. Can you try to take the ABSOLUTE address of _end instead of RAM_START_ADDRESS? Does it still work?

Hi Thomas

Thanks for your reply.

> your _end symbol is defined relative to the start of the .bss section
> (it evaluates as an offset from the beginning of the .bss section)

No - it's absolute already as shown in the map file:

                0x200017b0 _end = .

As are all of the other symbols used in the original calculation:

                0x20000000 RAM_START_ADDRESS = 0x20000000
                0x00010000 RAM_SIZE = 0x10000
                0x00002000 MAIN_STACK_SIZE = 0x2000
                0x00001000 PROCESS_STACK_SIZE = 0x1000

In spite of this the original calculation (which works in an older version of ld) gives the wrong result even though plugging in the values above gives the correct one.

.heap 0x200017b0 0x6000fda0
                0x200017b0 __heap_start__ = .
                0x6000fda0 . = (. + ((((RAM_START_ADDRESS + RAM_SIZE) - PROCESS_STACK_SIZE) - MAIN_STACK_SIZE) - _end))
 *fill* 0x200017b0 0x6000fda0
                0x80011550 . = ALIGN (0x10)
                0x80011550 _eheap = .

.stack 0x80011550 0x3000
                0x80011550 __stack_start__ = .

I should have said that I already tried ABSOLUTE(_end) but that gave the same wrong result.

.heap 0x200017b0 0x2000d000
                0x200017b0 __heap_start__ = .
                0x2000d000 . = (. + ((((RAM_START_ADDRESS + RAM_SIZE) - PROCESS_STACK_SIZE) - MAIN_STACK_SIZE) - ABSOLUTE (_end)))
 *fill* 0x200017b0 0x2000d000
                0x4000e7b0 . = ALIGN (0x10)
                0x4000e7b0 _eheap = .

Only ABSOLUTE(RAM_START_ADDRESS) or ORIGIN(ram) cause the calculation to return the correct result.

.heap 0x200017b0 0xb850
                0x200017b0 __heap_start__ = .
                0x2000d000 . = (. + ((((ABSOLUTE (RAM_START_ADDRESS) + RAM_SIZE) - PROCESS_STACK_SIZE) - MAIN_STACK_SIZE) - _end))
 *fill* 0x200017b0 0xb850
                0x2000d000 . = ALIGN (0x10)
                0x2000d000 _eheap = .

.heap 0x200017b0 0xb850
                0x200017b0 __heap_start__ = .
                0x2000d000 . = (((ORIGIN (ram) + RAM_SIZE) - PROCESS_STACK_SIZE) - MAIN_STACK_SIZE)
 *fill* 0x200017b0 0xb850
                0x2000d000 . = ALIGN (0x10)
                0x2000d000 _eheap = .

.stack 0x2000d000

Seems to me that this is a change in ld from how it used to work (since the original expression returns the correct result in an older ld but not in this version) or it's a bug in ld (or this specific build of ld). But I cannot find any evidence to support either hypothesis to date.

I will most likely go with one of the expressions that work (assuming that it also works with the older tools as I need backward compatibility) but I would like to understand this better and why it works different (and incorrectly?) in the latest ld but not an older version.

Thanks.

Sorry, I'm still lost, especially at the initial error. The output map when using ABSOLUTE(_end) makes a bit more sense but the original error don't make any. I tried to read more of the ld documentation, especially about its lazy evaluation and how it evaluate an expression depending on whether it's in an output section or not but still got nowhere.

My feeling is that there might be an information missing. Is it possible for you to show us the whole linker script?

Best regards.

Hi Thomas - thanks for looking into this. Much appreciated.
Here is the ld script in full.
Just to reiterate this works fine with the earlier version of ld (from CodeSourcery) mentioned earlier.
But it fails with the current GCC ARM Embedded ld.

/*******************************************************************************
 * (c) Copyright 2012-2014 Microsemi SoC Products Group. All rights reserved.
 *
 * SmartFusion2 Cortex-M3 linker script for creating a SoftConsole downloadable
 * debug image executing in SmartFusion2 internal eSRAM.
 *
 * SVN $Revision: 6693 $
 * SVN $Date: 2014-07-08 12:22:53 +0100 (Tue, 08 Jul 2014) $
 */

OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
GROUP(-lc -lgcc -lm)
OUTPUT_ARCH(arm)
ENTRY(Reset_Handler)
SEARCH_DIR(.)
__DYNAMIC = 0;

/*******************************************************************************
 * Start of board customization.
 *******************************************************************************/
MEMORY
{
  /* SmartFusion2 internal eSRAM */
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64k
}

RAM_START_ADDRESS = 0x20000000; /* Must be the same value MEMORY region ram ORIGIN above. */
RAM_SIZE = 64k; /* Must be the same value MEMORY region ram LENGTH above. */
MAIN_STACK_SIZE = 8k; /* Cortex main stack size. */
PROCESS_STACK_SIZE = 4k; /* Cortex process stack size (only available with OS extensions).*/

/* Please note that unassigned RAM will be allocated to the .heap section. */

/*******************************************************************************
 * End of board customization.
 *******************************************************************************/

PROVIDE (__main_stack_start = RAM_START_ADDRESS + RAM_SIZE);
PROVIDE (__process_stack_start = __main_stack_start - MAIN_STACK_SIZE);
PROVIDE (_estack = __main_stack_start);
PROVIDE (__mirrored_nvm = 0); /* Indicate to startup code that NVM is not mirrored to VMA address .text copy is required. */

/*
 * Remap instruction for startup code and debugger:
 * 0: remap eNVM to address 0x00000000
 * 1: remap eSRAM to address 0x00000000
 * 2: remap external DDR memory to address 0x00000000
 */
PROVIDE (__smartfusion2_memory_remap = 1);

SECTIONS
{
  .vector_table :
  {
    __vector_table_load = LOADADDR(.vector_table);
    __vector_table_start = .;
    __vector_table_vma_base_address = .;
    KEEP(*(.isr_vector))
    . = ALIGN(0x10);
    _evector_table = .;
  } >ram

  .init :
  {
    /* SystemInit() is called before relocation to RAM so keep in ROM */
    *(.boot_code)
    *system_m2sxxx.o(.text*)
    *sys_config.o(.rodata*)
    . = ALIGN(0x10);
  } >ram

  .text :
  {
    CREATE_OBJECT_SYMBOLS
    __text_load = LOADADDR(.text);
    __text_start = .;
    *(.text .text.* .gnu.linkonce.t.*)
    *(.plt)
    *(.gnu.warning)
    *(.glue_7t) *(.glue_7) *(.vfp11_veneer)

    . = ALIGN(0x4);
    /* These are for running static constructors and destructors under ELF. */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*crtend.o(.ctors))
    KEEP (*crtbegin.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*crtend.o(.dtors))

    *(.rodata .rodata.* .gnu.linkonce.r.*)

    *(.ARM.extab* .gnu.linkonce.armextab.*)
    *(.gcc_except_table)
    *(.eh_frame_hdr)
    *(.eh_frame)

    KEEP (*(.vector_table))
    KEEP (*(.init))
    KEEP (*(.fini))

    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(.fini_array))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE_HIDDEN (__fini_array_end = .);
    . = ALIGN(0x10);
  } >ram
  /* .ARM.exidx is sorted, so has to go in its own output section. */
   __exidx_start = .;
  .ARM.exidx :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  } >ram
  __exidx_end = .;
  _etext = .;
  PROVIDE(__text_end = .);

  .data :
  {
    __data_load = LOADADDR (.data);
    _sidata = LOADADDR (.data);
    __data_start = .;
    _sdata = .;
    KEEP(*(.jcr))
    *(.got.plt) *(.got)
    *(.shdata)
    *(.data .data.* .gnu.linkonce.d.*)
    . = ALIGN(0x10);
    _edata = .;
  } >ram

  .bss :
  {
    __bss_start__ = . ;
    _sbss = .;
    *(.shbss)
    *(.bss .bss.* .gnu.linkonce.b.*)
    *(COMMON)
    . = ALIGN(0x10);
    __bss_end__ = .;
    _end = .;
    __end = _end;
    _ebss = .;
    PROVIDE(end = .);
  } >ram

  .heap :
  {
    __heap_start__ = .;
    /* . = ORIGIN(ram) + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE; */
    /* . += (ABSOLUTE(RAM_START_ADDRESS) + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE - _end); */
    . += (RAM_START_ADDRESS + RAM_SIZE - PROCESS_STACK_SIZE - MAIN_STACK_SIZE - _end);
    . = ALIGN(0x10);
    _eheap = .;
  } >ram

  .stack :
  {
    __stack_start__ = .;
    . += PROCESS_STACK_SIZE;
    . = ALIGN(4);
    . += MAIN_STACK_SIZE;
    . = ALIGN(0x10);
    _estack = .;
  } >ram

  .stab 0 (NOLOAD) :
  {
    *(.stab)
  }

  .stabstr 0 (NOLOAD) :
  {
    *(.stabstr)
  }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0. */
  /* DWARF 1 */
  .debug 0 : { *(.debug) }
  .line 0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo 0 : { *(.debug_srcinfo) }
  .debug_sfnames 0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges 0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev 0 : { *(.debug_abbrev) }
  .debug_line 0 : { *(.debug_line) }
  .debug_frame 0 : { *(.debug_frame) }
  .debug_str 0 : { *(.debug_str) }
  .debug_loc 0 : { *(.debug_loc) }
  .debug_macinfo 0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames 0 : { *(.debug_varnames) }
  .note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }
  .ARM.attributes 0 : { KEEP (*(.ARM.attributes)) }
  /DISCARD/ : { *(.note.GNU-stack) *(.isr_vector) }
}

Hi Thomas. Wow! Thanks a lot for digging so deeply into this. Much appreciated.
Your analysis certainly seems to add up alright.
So I guess the fact that the calculation returned the result that I expected with the older version of ld was probably down to a bug in that version?

Thanks again.

It might also be due to a change of behavior or the toolchain being built with different defaults. I don't know the details of Mentor Sourcery CodeBench toolchain so I can only guess.

Thanks Thomas Preud'homme, that solved my question.