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.