BiteSizedChunks.comLearn one small thing at a time.
Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 489 of 9366. Embedded Software Construction and ToolchainsFree lesson

Analyzing Symbol Tables for Memory Allocation Verification

Students will utilize nm to inspect symbol tables, confirming that functions and variables are mapped to the correct memory regions.

In this lesson, you will learn how to use the nm utility to verify that your firmware components are physically located in the expected memory regions of your target device.

Inspecting the Symbol Table with nm

When you compile an embedded project, the linker uses a linker script to assign code and data to specific memory addresses, such as Flash or RAM. However, complex build configurations or overlapping memory sections can sometimes result in variables or functions being placed where they don’t belong. The nm tool, part of the GNU Binutils suite, reads the symbol table of an object file or executable, revealing the name, type, and memory address of every function and variable.

To use it, navigate to your build output directory and run:

arm-none-eabi-nm -S --defined-only my_firmware.elf | sort

The -S flag displays the size of each symbol, and --defined-only filters out external references that haven't been resolved yet.

Verifying Memory Mappings

Once you have the output, you can correlate the addresses with your linker script's memory regions. For example, if your startup.c file defines a critical vector_table that must reside at 0x08000000 (the start of Flash), nm will show you exactly where it landed:

08000000 00000180 R vector_table
20000000 00000400 D global_config_struct

In this output:

  • The R indicates a symbol in the Read-Only section (Flash).
  • The D indicates a symbol in the Data section (Initialized RAM).

If you see a symbol like global_config_struct mapped to 0x0800... when it should be in RAM, you know your linker script or your __attribute__((section(...))) declarations are misconfigured. By regularly checking the symbol table, you catch alignment errors or section overflows before they lead to hard faults or corrupted data during runtime. This process turns the "black box" of binary linking into a transparent audit, ensuring your firmware conforms exactly to the hardware memory map you designed.

Key Takeaway: The nm utility provides a critical bridge between your linker script definitions and the actual binary output, allowing you to mathematically verify that every variable and function resides within its intended memory partition.