Get Simple Application Compiled
Let's try to compile simple application of infinite loop, called test_cpp_simple.
A linker script is required to get all the generated objects successfully linked. It states what code/data sections need to be loaded at what addresses as well as defines several symbols that may be required by the sources. Here is a good manual of linker script syntax and here is the linker script I use to get applications linked for Raspberry Pi platform.
Depending on your compiler, the link may fail because some symbols are missing. For example __exidx_start and __exidx_end are needed when the application is compiled with exceptions support, or __bss_start__ and __bss_end__ may be required by standard library if it contains the code for zeroing .bss section.
Every application must have a startup code usually written in Assembler. This startup code must perform the following steps: 1. Write the interrupt vector table at appropriate location (usually at address 0x0000). 1. Set the stack pointers for every runtime mode. 1. Zero the .bss section 1. Call constructors of global (static) objects (applicable only to C++) 1. Call the main function.
It may happen that compiler generates some startup code for you, especially if you haven't excluded standard library (stdlib) from compilation. To check whether this is the case, we need to analyse assembler listing of the successfully compiled and linked image binary. All the generated files for a test application will reside in <build_dir>/src/test_cpp/<app_name>. The assembler listing file will have kernel.list name.
Side note: the assembler listing can be generated using the following command:
arm-none-eabi-objdump -D -S app_binary > app.list
Open the listing file and look for function with CRT string in it. CRT stands for “C Run-Time”. When using this compiler, the function that compiler has generated, is called _mainCRTStartup. Let's take closer look what this function does.
00008198 <_mainCRTStartup>:Load the address of the end of the RAM and assign its value to stack pointer (sp).
8198: e59f30f0 ldr r3, [pc, #240] ; 8290 <_mainCRTStartup+0xf8>
819c: e3530000 cmp r3, #0
81a0: 059f30e4 ldreq r3, [pc, #228] ; 828c <_mainCRTStartup+0xf4>
81a4: e1a0d003 mov sp, r3Set the value of sp for various modes, the sizes of the stacks are determined by the compiler itself.
81a8: e10f2000 mrs r2, CPSR
81ac: e312000f tst r2, #15
81b0: 0a000015 beq 820c <_mainCRTStartup+0x74>
81b4: e321f0d1 msr CPSR_c, #209 ; 0xd1
81b8: e1a0d003 mov sp, r3
81bc: e24daa01 sub sl, sp, #4096 ; 0x1000
81c0: e1a0300a mov r3, sl
81c4: e321f0d7 msr CPSR_c, #215 ; 0xd7
81c8: e1a0d003 mov sp, r3
81cc: e2433a01 sub r3, r3, #4096 ; 0x1000
81d0: e321f0db msr CPSR_c, #219 ; 0xdb
81d4: e1a0d003 mov sp, r3
81d8: e2433a01 sub r3, r3, #4096 ; 0x1000
81dc: e321f0d2 msr CPSR_c, #210 ; 0xd2
81e0: e1a0d003 mov sp, r3
81e4: e2433a02 sub r3, r3, #8192 ; 0x2000
81e8: e321f0d3 msr CPSR_c, #211 ; 0xd3
81ec: e1a0d003 mov sp, r3
81f0: e2433902 sub r3, r3, #32768 ; 0x8000
81f4: e3c330ff bic r3, r3, #255 ; 0xff
81f8: e3c33cff bic r3, r3, #65280 ; 0xff00
81fc: e5033004 str r3, [r3, #-4]
8200: e9532000 ldmdb r3, {sp}^
8204: e38220c0 orr r2, r2, #192 ; 0xc0
8208: e121f002 msr CPSR_c, r2
820c: e243a801 sub sl, r3, #65536 ; 0x10000
8210: e3b01000 movs r1, #0
8214: e1a0b001 mov fp, r1
8218: e1a07001 mov r7, r1Load the addresses of __bss_start__ and __bss_end__ symbols and zero all the area in between.
821c: e59f0078 ldr r0, [pc, #120] ; 829c <_mainCRTStartup+0x104>
8220: e59f2078 ldr r2, [pc, #120] ; 82a0 <_mainCRTStartup+0x108>
8224: e0522000 subs r2, r2, r0
8228: eb00004a bl 8358 <memset>
... Then comes some code, purpose of which is not clearCall the __libc_init_array function provided by standard library which will initialise all the global objects. It will treat the area between __init_array_start and __init_array_end as list of pointers to initialisation functions and call them one by one.
8278: eb000014 bl 82d0 <__libc_init_array>Call the main function.
8284: eb000010 bl 82cc <main>If main function returns for some reason, call the exit function, which probably must be implemented as infinite loop or jumping back to the beginning of the startup code.
8288: eb000008 bl 82b0 <exit>Here comes local data
828c: 00080000 andeq r0, r8, r0
8290: 04008000 streq r8, [r0], #-0
...
829c: 00008458 andeq r8, r0, r8, asr r4
82a0: 00008474 andeq r8, r0, r4, ror r4The only missing stage in the startup process is updating the interrupt vector table. After the latter is updated properly, it is possible to call the provided _mainCRTStartup function. However, if your compiler doesn't provide such function you have no other choice but to write the whole startup code yourself. Here is an example of such code.
Please note, that .bss section by definition contains uninitialised data that must be zeroed at startup. Even if you don't have uninitialised variables in your code, zeroing .bss is a must have operation. This is because compiler might put variables that are explicitly initialised to 0 into the .bss for performance reasons and count on this section being zeroed at startup.
Also note, that pointers to initialisation functions of global variables reside in .init.array section. To initialise your global objects you just iterate over all entries in this section and call them one by one.
To implement the missing stage for use the following assembler instructions:
_entry:
ldr pc,reset_handler_ptr ;@ Processor Reset handler
ldr pc,undefined_handler_ptr ;@ Undefined instruction handler
ldr pc,swi_handler_ptr ;@ Software interrupt
ldr pc,prefetch_handler_ptr ;@ Prefetch/abort handler.
ldr pc,data_handler_ptr ;@ Data abort handler/
ldr pc,unused_handler_ptr ;@
ldr pc,irq_handler_ptr ;@ IRQ handler
ldr pc,fiq_handler_ptr ;@ Fast interrupt handler.
;@ Set the branch addresses
reset_handler_ptr: .word reset
undefined_handler_ptr: .word hang
swi_handler_ptr: .word hang
prefetch_handler_ptr: .word hang
data_handler_ptr: .word hang
unused_handler_ptr: .word hang
irq_handler_ptr: .word irq_handler
fiq_handler_ptr: .word hang
reset:
;@ Disable interrupts
cpsid if
;@ Copy interrupt vector to its place
ldr r0,=_entry
mov r1,#0x0000
;@ Here we copy the branching instructions
ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}
;@ Here we copy the branching addresses
ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}Please note that at interrupt vector table that resides at address 0x0000 contains branch instructions to the appropriate handlers, not just addresses of the handlers. Let's take a closer look how these branching instructions look in our assembler listing file:
_entry:
800c: e59ff018 ldr pc, [pc, #24] ; 802c <reset_handler_ptr>
8010: e59ff018 ldr pc, [pc, #24] ; 8030 <undefined_handler_ptr>
8014: e59ff018 ldr pc, [pc, #24] ; 8034 <swi_handler_ptr>
8018: e59ff018 ldr pc, [pc, #24] ; 8038 <prefetch_handler_ptr>
801c: e59ff018 ldr pc, [pc, #24] ; 803c <data_handler_ptr>
8020: e59ff018 ldr pc, [pc, #24] ; 8040 <unused_handler_ptr>
8024: e59ff018 ldr pc, [pc, #24] ; 8044 <irq_handler_ptr>
8028: e59ff018 ldr pc, [pc, #24] ; 8048 <fiq_handler_ptr>
0000802c <reset_handler_ptr>:
802c: 0000804c andeq r8, r0, ip, asr #32
00008030 <undefined_handler_ptr>:
8030: 000082b4 ; <UNDEFINED> instruction: 0x000082b4
00008034 <swi_handler_ptr>:
8034: 000082b4 ; <UNDEFINED> instruction: 0x000082b4
00008038 <prefetch_handler_ptr>:
8038: 000082b4 ; <UNDEFINED> instruction: 0x000082b4
0000803c <data_handler_ptr>:
803c: 000082b4 ; <UNDEFINED> instruction: 0x000082b4
00008040 <unused_handler_ptr>:
8040: 000082b4 ; <UNDEFINED> instruction: 0x000082b4
00008044 <irq_handler_ptr>:
8044: 000082b8 ; <UNDEFINED> instruction: 0x000082b8
00008048 <fiq_handler_ptr>:
8048: 000082b4 ; <UNDEFINED> instruction: 0x000082b4The branching instructions load address of the interrupt function to “pc” register. However the address of the function is stored somewhere and compiler generates access to this storage using relative offset to current “pc” register. This is the reason why we have to copy not just the branching instructions, but also the storage area where addresses of interrupt routines are stored:
;@ Copy interrupt vector to its place
ldr r0,=_entry
mov r1,#0x0000
;@ Here we copy the branching instructions
ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}
;@ Here we copy the branching addresses
ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}Last updated
Was this helpful?