Now let's examine our ldr instruction:
Our original instruction was ldr r2, =len_start_msg this was resolved by the assembler to ldr r2, [pc, #44]
len_start_msg is a variable symbol, so =len_start_msg will evaluate to loading the value for that symbol.
pc, #44 takes the current pc register value and adds 44 to it.
[pc, #44] evaluates the data at that address and loads it to the destination register r2.
We know that the pc value will be two instructions ahead, so if we add 0x10080 + 8 + 44:
> 0x10080 <_start+12> ldr r2, [pc, #44]
len_start_msg is a variable symbol, so =len_start_msg will evaluate to loading the value for that symbol.
pc, #44 takes the current pc register value and adds 44 to it.
[pc, #44] evaluates the data at that address and loads it to the destination register r2.
We know that the pc value will be two instructions ahead, so if we add 0x10080 + 8 + 44:
(gdb) print/x (0x10080 + 8 + 44) $2 = 0x100b4
And we know that the length of "At start\n" should be 9 bytes, so 0x09 should be stored at 0x100b4:
(gdb) x /1xb $2 0x100b4 <start_msg+12>: 0x09
And we can see that 0x09 is indeed stored at that location.
Notice when we printed our address calculation, GDB automatically stored it in the variable $2 to allow for easy referencing.
Let's step forward in our program to the next ldr instruction:
Notice when we printed our address calculation, GDB automatically stored it in the variable $2 to allow for easy referencing.
Let's step forward in our program to the next ldr instruction:
0x1008c <write_hello_msg+4> ldr r1, [pc, #36] ; 0x100b8 <start_msg+16>
For this instruction, the assembly is loading the value [] stored at the offset of
the pc register + 36 bytes.
This should evaluate to the value stored at:
This should evaluate to the value stored at:
(gdb) print /x (0x1008c + 8 + 36) $3 = 0x100b8
What is stored at 0x100b8 ?
(gdb) x /4xb $3 0x100b8 <start_msg+16>: 0xbc 0x00 0x02 0x00
This is the memory addres 0x000200bc in little endian.
Where is this address?
Where is this address?
(gdb) info file Symbols from "/home/pete/Documents/ASM/hello_world/ARM32/hello_arm32". Remote target using gdb-specific protocol: `/home/pete/Documents/ASM/hello_world/ARM32/hello_arm32', file type elf32-littlearm. Entry point: 0x10074 0x00010074 - 0x000100bc is .text 0x000200bc - 0x000200cb is .data While running this, GDB does not access memory from... Local exec file: `/home/pete/Documents/ASM/hello_world/ARM32/hello_arm32', file type elf32-littlearm. Entry point: 0x10074 0x00010074 - 0x000100bc is .text 0x000200bc - 0x000200cb is .data (gdb)
We can see it is in our data section:
(gdb) x /13cb 0x000200bc 0x200bc: 72 'H' 101 'e' 108 'l' 108 'l' 111 'o' 32 ' ' 87 'W' 111 'o' 0x200c4: 114 'r' 108 'l' 100 'd' 33 '!' 10 '\n'
And there is our Hello World! message.
The assembler retrieved the address of our hello_msg label from the .data section,
then it appended that address value to the end of our .text section of code,
then it loaded that address into the r1 register by offsetting from the pc register
to the memory address in the .text section that contained the memory address for the actual data.
The assembler retrieved the address of our hello_msg label from the .data section,
then it appended that address value to the end of our .text section of code,
then it loaded that address into the r1 register by offsetting from the pc register
to the memory address in the .text section that contained the memory address for the actual data.