Hello everybody.

I'm compiling this piece of assembly and observing a strange behavior.

.section .vectors
   .code 32
   .arm
EXCEPTION_VECTORS:
      ldr   pc, resetvec
      ldr   pc, undefvec
      ldr   pc, swivec
      ldr   pc, pabtvec
      ldr   pc, dabtvec
      .word   0
      ldr   pc, irqvec
      ldr   pc, fiqvec
resetvec:   .word   _startup
undefvec:   .word   Undef_Handler
swivec:      .word   Swi_Handler
pabtvec:   .word   Pabt_Handler
dabtvec:   .word   Dabt_Handler
irqvec:      .word   IRQ_Handler_Entry
fiqvec:      .word   FIQ_Handler_Entry

   .section .text
   .code 32
   .arm
   .global _startup
   .extern main
Undef_Handler:
   B   Undef_Handler
Swi_Handler:
   B   Undef_Handler
Pabt_Handler:
   B   Undef_Handler
Dabt_Handler:
   B   Dabt_Handler
IRQ_Handler_Entry:
...

The .vectors section never appears in the resulting HEX code, as well I
can't find it in the extended listing generated by command:

arm-elf-objdump -h -S -C main.elf

This is what I find in the listing:

main.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .vectors      0000003c  00000000  00000000  0000452c  2**0
                  CONTENTS, READONLY
  1 .text         000004f0  0010403c  0010403c  0000403c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .comment      00000048  00000000  00000000  00004568  2**0
                  CONTENTS, READONLY
  3 .debug_aranges 000000a8  00000000  00000000  000045b0  2**3
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_pubnames 00000192  00000000  00000000  00004658  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   00002055  00000000  00000000  000047ea  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 000005fe  00000000  00000000  0000683f  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   00000380  00000000  00000000  00006e3d  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  000001ac  00000000  00000000  000071c0  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    00000a48  00000000  00000000  0000736c  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_loc    0000015d  00000000  00000000  00007db4  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .ARM.attributes 00000010  00000000  00000000  00007f11  2**0
                  CONTENTS, READONLY
 12 .debug_ranges 00000138  00000000  00000000  00007f28  2**3
                  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:

0010403c <Undef_Handler>:
  10403c:   eafffffe    b   10403c <Undef_Handler>
...

The assembly code is compiled with the following parameters:

arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -x
assembler-with-cpp -Wa,-adhlns=Cstartup.lst,-gdwarf-2 Cstartup.S -o
Cstartup.o

The linker script I use is:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_startup)

/* Size of bootloader region */
BOOTSIZE = 0x00004000;

/* Size of application */
APPSIZE = 0x00005000;

/* Memory layout */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00104000, LENGTH = 0x00005000
  RAM (rw) : ORIGIN = 0x00200000, LENGTH = 0x00004000
  REMAPPED (rwx) : ORIGIN = 0x00000000, LENGTH = LENGTH(RAM)
}

/* Section Definitions */
SECTIONS
{
  _stack = 0x00200000 + 16K;

  /* place vectors at 0x0 */
  .vectors :
  {
    _vectors_start = .;
    *(.vectors)
    KEEP(*(.vectors))
    _vectors_end = .;
  } >REMAPPED AT >ROM

  /* first section is .text which is used for code */
  .text : { *Cstartup.o (.text) } >ROM =0
  .text :
  {
    /* ARM exception vectors */
    /*_vectors_start = .;
    KEEP(*(.vectors))
    _vectors_end = .;
    KEEP(*Cstartup.o (.text))*/   /* Startup code */
    *(.text)      /* code */
    *(.rodata)      /* read-only data (constants) */
    *(.rodata*)

    *(.glue_7t) *(.glue_7)

  } >ROM =0
...

As you see I link vectors section to 0x0 address, so it should work just
fine as far as I understand.

Does anybody have an idea what the problem is?
Thanks a lot for any help!

Your linker script looks strange but it's difficult to "patch" without a
complete minimal example-project. Anyway, there is not need to
"reinvent" the wheel for vectors in RAM/remapping:

Read the the "Building Bare-Metal ARM Systems with GNU" Tutorial from
Miro Samek (available from embedded.com and from the Quantum Leaps
Website). This explains the steps needed to place the vectors in RAM.

You can also take a look into the code from my "AT91 gamma"-example, it
also demonstrates vectors in RAM/remapping:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_gamma

Martin Thomas wrote:
> Your linker script looks strange but it's difficult to "patch" without a
> complete minimal example-project. Anyway, there is not need to
> "reinvent" the wheel for vectors in RAM/remapping:

What's wrong with the linker script? Can you tell more about it?

> Read the the "Building Bare-Metal ARM Systems with GNU" Tutorial from
> Miro Samek (available from embedded.com and from the Quantum Leaps
> Website). This explains the steps needed to place the vectors in RAM.

That series of articles is certainly great, and I'm reading them. In my
opinion though, the best way to learn and understand something is to
implement that "something" yourself.

> You can also take a look into the code from my "AT91 gamma"-example, it
> also demonstrates vectors in RAM/remapping:
> 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_gamma

Thanks a lot, it has lots of materials for researching and studying.