Reading a Map File and Disassembly

Adding -Wl,-Map=app.map to the link command makes the linker write a map file, the complete record of its decisions. The GNU ld manual lists what it contains: where each object file’s sections were placed, how common symbols were allocated, every archive member that was included and the symbol that caused it, and the values assigned to symbols (global symbols and those the linker script defines; static locals are not listed). An abridged, illustrative excerpt:

Archive member included to satisfy reference by file (symbol)

libboard.a(board.o)           build/main.o (board_init)
libgpio.a(gpio.o)             libboard.a(board.o) (gpio_init)

Memory Configuration

Name             Origin             Length             Attributes
FLASH            0x10000000         0x00200000         xr
RAM              0x20000000         0x00040000         xrw

Linker script and memory map

.text           0x10000100     0xbc48
 .text.led_on   0x10000234       0x18 build/led.o
 .text.gpio_put 0x10000410       0x2c libgpio.a(gpio.o)

Read it from the top. The first block answers “why is this library code in my image?”: board.o was extracted from libboard.a because main.o referred to board_init, and gpio.o because board.o then referred to gpio_init, the chain lesson 3 described. The memory configuration repeats the script’s MEMORY block. Then, for each output section, every input section with its address, its size in bytes, and the file it came from: led_on is 0x18 = 24 bytes at 0x1000_0234 from led.o. When you use --gc-sections, the map file also lists the discarded input sections, which answers “why is my function missing?” Linker-generated stubs for far calls (lesson 2) appear here too, as small input sections the linker created itself.

arm-none-eabi-objdump -d app.elf disassembles every executable section. Each line gives the address, the encoding, and the instruction:

10000234 <led_on>:
10000234:  b510       push  {r4, lr}
1000023a:  f000 f8e9  bl    10000410 <gpio_put>
1000023e:  4a02       ldr   r2, [pc, #8]  @ (10000248 <led_on+0x14>)

Thumb encodings are shown as 16-bit halfwords, as numbers; in memory each halfword is stored little-endian, so b510 occupies the bytes 10 b5. objdump names branch targets and literal addresses from the symbol table, which is why an ELF with symbols is far more useful than a raw binary. With -S and a build compiled with -g, it interleaves the source lines each instruction came from; the crash-dump question from the opening is then answered by searching the listing for the address.

↑ This step uses the figure at the top of the page.

Two things in a listing surprise newcomers. Literal pools: constants and addresses that do not fit in an instruction are stored as data words right after the function, and loaded with PC-relative ldr. GCC marks them with mapping symbols, so objdump prints them as .word; from a stripped file or a raw binary, where those markers are gone, it disassembles them as if they were instructions and prints nonsense. And compiler reordering: at -O2 the instructions for one source line may be scattered and interleaved with others, so the listing is the truth and the source is only an approximation of it.

Take the listing above and trust only the bits.

The BL at 0x1000_023A: f000 f8e9. In the first halfword, bit 10 is the sign S = 0 and the low ten bits imm10 = 0. In the second, J1 (bit 13) = 1, J2 (bit 11) = 1 and imm11 (low eleven bits) = 0xE9. The architecture defines $I_1 = \lnot(J_1 \oplus S) = 0$ and $I_2 = \lnot(J_2 \oplus S) = 0$, and the offset is the concatenation $S{:}I_1{:}I_2{:}\text{imm10}{:}\text{imm11}{:}0$:

which is gpio_put, exactly what objdump printed and what lesson 1 computed from the other direction.

The LDR at 0x1000_023E: 4a02. This is LDR r2, [PC, #imm8×4] with imm8 = 2. The address is computed from the PC value (the instruction’s address + 4), rounded down to a multiple of 4:

At 0x1000_0248 the listing shows the literal word 0x2000_0010: the address of led_count, patched there by the R_ARM_ABS32 relocation of lesson 2.