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.
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.