title: Understanding the Location Counter of GNU Linker Scripts
body: <p>I'm working on a university project where I'm writing software for an Atmel SAM7S256 microcontroller from the ground up. This is more in depth than other MCUs I've worked with before, as a knowledge of linker scripts and assembly language is necessary this time around.</p>
  <p>I've been really scrutinizing example projects for the SAM7S chips in order to fully understand how to start a SAM7/ARM project from scratch. A notable example is Miro Samek's &quot;Building Bare-Metal ARM Systems with GNU&quot; tutorial found <a href="https://web.archive.org/web/20120107105306/http://www.state-machine.com/resources/articles.php" rel="nofollow noreferrer" title="here">here</a> (where the code in this question is from). I've also spent a lot of time reading the linker and assembler documentation from sourceware.org.</p>
  <p>I'm quite happy that I understand the following linker script for the most part. There's just one thing involving the location counter that doesn't make sense to me. Below is the linker script provided with the above tutorial:</p>
  <pre><code>OUTPUT_FORMAT(&quot;elf32-littlearm&quot;, &quot;elf32-bigarm&quot;, &quot;elf32-littlearm&quot;)
  OUTPUT_ARCH(arm)
  ENTRY(_vectors)
  
  MEMORY {                                       /* memory map of AT91SAM7S64 */
      ROM (rx)  : ORIGIN = 0x00100000, LENGTH = 64k
      RAM (rwx) : ORIGIN = 0x00200000, LENGTH = 16k
  }
  
  /* The sizes of the stacks used by the application. NOTE: you need to adjust */
  C_STACK_SIZE   = 512;
  IRQ_STACK_SIZE = 0;
  FIQ_STACK_SIZE = 0;
  SVC_STACK_SIZE = 0;
  ABT_STACK_SIZE = 0;
  UND_STACK_SIZE = 0;
  
  /* The size of the heap used by the application. NOTE: you need to adjust   */
  HEAP_SIZE = 0;
  
  SECTIONS {
  
      .reset : {
          *startup.o (.text)  /* startup code (ARM vectors and reset handler) */
          . = ALIGN(0x4);
       } &gt;ROM
  
      .ramvect : {                        /* used for vectors remapped to RAM */
          __ram_start = .;
          . = 0x40;
      } &gt;RAM
  
      .fastcode : {
          __fastcode_load = LOADADDR (.fastcode);
          __fastcode_start = .;
  
          *(.glue_7t) *(.glue_7)
          *isr.o (.text.*)
          *(.text.fastcode)
          *(.text.Blinky_dispatch)
          /* add other modules here ... */
  
          . = ALIGN (4);
          __fastcode_end = .;
      } &gt;RAM AT&gt;ROM
  
      .text : {
          . = ALIGN(4);
          *(.text)                                   /* .text sections (code) */
          *(.text*)                                 /* .text* sections (code) */
          *(.rodata)           /* .rodata sections (constants, strings, etc.) */
          *(.rodata*)         /* .rodata* sections (constants, strings, etc.) */
          *(.glue_7) /* glue arm to thumb (NOTE: placed already in .fastcode) */
          *(.glue_7t)/* glue thumb to arm (NOTE: placed already in .fastcode) */
  
          KEEP (*(.init))
          KEEP (*(.fini))
  
          . = ALIGN(4);
          _etext = .;                         /* global symbol at end of code */
      } &gt;ROM
  
      .preinit_array : {
          PROVIDE_HIDDEN (__preinit_array_start = .);
          KEEP (*(SORT(.preinit_array.*)))
          KEEP (*(.preinit_array*))
          PROVIDE_HIDDEN (__preinit_array_end = .);
      } &gt;ROM
  
      .init_array : {
          PROVIDE_HIDDEN (__init_array_start = .);
          KEEP (*(SORT(.init_array.*)))
          KEEP (*(.init_array*))
          PROVIDE_HIDDEN (__init_array_end = .);
      } &gt;ROM
  
      .fini_array : {
          PROVIDE_HIDDEN (__fini_array_start = .);
          KEEP (*(.fini_array*))
          KEEP (*(SORT(.fini_array.*)))
          PROVIDE_HIDDEN (__fini_array_end = .);
      } &gt;ROM
  
      .data : {
          __data_load = LOADADDR (.data);
          __data_start = .;
          *(.data)                                          /* .data sections */
          *(.data*)                                        /* .data* sections */
          . = ALIGN(4);
          _edata = .;
      } &gt;RAM AT&gt;ROM
  
      .bss : {
          __bss_start__ = . ;
          *(.bss)
          *(.bss*)
          *(COMMON)
          . = ALIGN(4);
          _ebss = .;                     /* define a global symbol at bss end */
          __bss_end__ = .;
      } &gt;RAM
  
      PROVIDE ( end = _ebss );
      PROVIDE ( _end = _ebss );
      PROVIDE ( __end__ = _ebss );
  
      .heap : {
          __heap_start__ = . ;
          . = . + HEAP_SIZE;
          . = ALIGN(4);
          __heap_end__ = . ;
      } &gt;RAM
  
      .stack : {
          __stack_start__ = . ;
  
          . += IRQ_STACK_SIZE;
          . = ALIGN (4);
          __irq_stack_top__ = . ;
  
          . += FIQ_STACK_SIZE;
          . = ALIGN (4);
          __fiq_stack_top__ = . ;
  
          . += SVC_STACK_SIZE;
          . = ALIGN (4);
          __svc_stack_top__ = . ;
  
          . += ABT_STACK_SIZE;
          . = ALIGN (4);
          __abt_stack_top__ = . ;
  
          . += UND_STACK_SIZE;
          . = ALIGN (4);
          __und_stack_top__ = . ;
  
          . += C_STACK_SIZE;
          . = ALIGN (4);
          __c_stack_top__ = . ;
  
          __stack_end__ = .;
      } &gt;RAM
  
      /* Remove information from the standard libraries */
      /DISCARD/ : {
          libc.a ( * )
          libm.a ( * )
          libgcc.a ( * )
      }
  }
  </code></pre>
  <p>Throughout the example (such as in the .ramvect, .fastcode and .stack sections) there are symbol definitions such as <code>__ram_start = .;</code>. These addresses are used by the startup assembly code and initialization C code in order to initialize the correct locations in the MCU's RAM.</p>
  <p>What I have a problem understanding, is how these symbol definitions result in the correct values being assigned. This does happen, the script is correct, I just don't understand how.</p>
  <p>The way I understand it, when you use the location counter within a section, it only contains a relative offset from the virtual memory address (VMA) of the section itself.</p>
  <p>So for example, in the line <code>__ram_start = .;</code>, I would expect __ram_start to be assigned a value of 0x0 - as it is assigned the value of the location counter at the very beginning of the .ramvect section. However, for the initialization code to work correctly (which it does), __ram_start must be getting assigned as 0x00200000 (the address for the beginning of RAM).</p>
  <p>I would have thought this would only work as intended if the line was instead <code>__ram_start = ABSOLUTE(.);</code> or <code>__ram_start = ADDR(.ramvect);</code>.</p>
  <p>The same goes for <code>__fastcode_start</code> and <code>__stack_start__</code>. They can't all be getting defined as address 0x0, otherwise the program wouldn't work. But the documentation <a href="https://sourceware.org/binutils/docs-2.21/ld/Location-Counter.html#Location-Counter" rel="nofollow noreferrer" title="linked here">linked here</a> seems to suggest that that's what should be happening. Here's the quote from the documentation:</p>
  <blockquote>
  <p>Note: . actually refers to the byte offset from the start of the current containing object. Normally this is the SECTIONS statement, whose start address is 0, hence . can be used as an absolute address. If . is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address.</p>
  </blockquote>
  <p>So the location counter values during those symbol assignments should be offsets from the corresponding section VMAs. So those &quot;_start&quot; symbols should <em>all</em> be getting set to 0x0. Which would break the program.</p>
  <p>So obviously I'm missing something. I suppose it could simply be that assigning the location counter value to a symbol (within a section) results in ABSOLUTE() being used by default. But I haven't been able to find a clear explanation anywhere that confirms this.</p>
  <p>Thanks in advance if anybody can clear this up.</p>