What a GNU ld map can answer
GNU ld's -Map report records where object files are mapped, how common symbols are allocated, which archive members were included, and symbol values. This page uses the Memory Configuration table as the source of region origins and lengths, then associates parsed output-section VMA ranges and their input-section records with those regions.
Mapped bytes versus high-water placement
Mapped bytes union the occupied output-section ranges, avoiding double counting if the report contains an overlap. High-water placement extends from the region origin through the highest section end, so it includes holes and alignment gaps below that point. Both are useful, but neither automatically equals an ELF file's loadable bytes: a section such as .data can have a RAM VMA and a separate flash load address.
How to review a build regression
Use maps generated by comparable toolchains and linker scripts. Region deltas show broad flash or RAM movement; section deltas locate categories such as code, constants, initialized data, or zero-initialized storage; source-path deltas identify likely object or archive contributors. Renamed sections or build paths appear as a removal plus an addition because this tool never guesses identity.
Interpretation boundary
A linker map is human-readable diagnostic output, not a stable interchange format. This parser targets common English GNU ld layouts and reports what it could attribute. It does not parse ELF program headers, DWARF, map symbols as runtime allocations, garbage-collected input not present in the final map, stack depth, heap peaks, dynamic allocation, compression, overlays, MPU settings, startup copying, or target correctness. Verify release limits with the linker, ELF inspection, and measurements on the actual target.
Frequently asked questions
Why can attributed object bytes differ from region usage?
Object totals sum the input-section rows that include a source path. Output sections may also contain padding, linker-generated data, assignments, common symbols, or constructs this bounded parser does not attribute. Region usage instead comes from output-section ranges.
Does .data count in RAM or flash?
Its VMA output range counts in the containing runtime region, commonly RAM. A printed load address is shown separately because initialized bytes may also occupy flash in the load image. The tool does not invent a second output section or double-count it in flash usage.
Can I use an IAR, Keil, or LLVM map?
Not unless it actually follows the required GNU ld headings and common record layout. Those tools have distinct formats. Failing visibly is safer than producing plausible but incorrect memory numbers.
Why is *default* omitted from the diagram?
GNU ld often prints a huge fallback address region. It remains in the audit table, but drawing it to scale would make the actual FLASH and RAM regions invisible.
Reference: GNU ld -Map and --print-map documentation.
Compare firmware bytes by address · Inspect an MCUboot image · Inspect an STM32 DfuSe package