In this lesson, you will learn how to use essential GNU binutils to inspect, audit, and debug your compiled ELF (Executable and Linkable Format) binaries.
Once your linker script has successfully combined objects into a final binary, the resulting file is a "black box" of machine code and metadata. To verify that your memory layout and symbols are correctly positioned, you need utilities that peer inside this structure.
Inspecting Symbol Tables with nm
The nm tool lists the symbols (function names, global variables) defined or referenced in your binary. If you find your firmware is crashing due to an undefined reference, nm is your first stop.
# List all symbols in the binary
arm-none-eabi-nm firmware.elf
Look for the letters next to each entry: T denotes a symbol in the .text (code) section, while D denotes initialized data. If you see a U, it signifies an "undefined" symbol—a classic sign that a library or object file was missing during the linking phase.
Disassembling with objdump
When you need to verify that your C code compiled into the expected machine instructions, objdump is indispensable. It allows you to interleave your C source code with the generated assembly, which is vital for verifying that a function was placed in a specific memory section (like RAM or FLASH) as defined in your linker script.
# Disassemble the code section
arm-none-eabi-objdump -d firmware.elf
Auditing Sections with readelf
While objdump focuses on instructions, readelf provides the structural metadata of the ELF file. By running arm-none-eabi-readelf -S firmware.elf, you can view the section headers. This is the ultimate "truth" for your memory layout; it confirms the exact start address and size of your .vectors, .text, .data, and .bss sections. If your binary size exceeds your microcontroller’s available FLASH, this is where you confirm which section is responsible for the bloat.
By integrating these tools into your workflow, you move from "guessing" why a binary isn't working to having a definitive, evidence-based understanding of exactly what the compiler and linker placed into your target hardware.
Key Takeaway: Tools like nm, objdump, and readelf allow you to verify that your memory layout, symbol resolutions, and instruction generation strictly adhere to your linker script’s requirements.