You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fbuild bloat: emit and preserve firmware.map automatically #491
fbuild bloat / fbuild symbols produces a useful per-symbol table from nm, but the archive / object / section columns come from the linker map (firmware.map). On a fresh fbuild build, no map file is emitted, so those columns are all - and bloat lookup cannot show callers, referencers, or per-archive rollups.
Repro on this branch (Windows, esp32s3 sketch):
fbuild build tests/platform/esp32s3 -e esp32s3
fbuild symbols tests/platform/esp32s3 --top 50
# → all ARCHIVE/OBJECT/SECTION columns are "-"
# → "Flash bytes by archive" rolls everything up under "(unattributed)"
find tests/platform/esp32s3/.fbuild -name '*.map' # → no results
find tests/platform/esp32s3/.fbuild -name 'build_info*.json' # → no results
The map is the difference between a generic top-N report and an actionable one (e.g. "12% of flash is libc.a/lib_a-vfprintf.o").
Proposed fix
When fbuild bloat (today: fbuild symbols) runs against a project directory, if no map sits next to the ELF:
Re-link with -Wl,-Map=firmware.map automatically (or pass it on every link by default during fbuild build — the cost is a few hundred KB of disk).
Likewise emit build_info.json (toolchain nm / c++filt paths) next to the ELF so --nm / --cppfilt don't have to be passed manually.
Option 1 (always emit during link) is cleaner and matches what PlatformIO / Arduino IDE do today — the map is a normal build product. Option 2 (lazy re-link on demand from fbuild bloat) avoids the disk cost but makes the first invocation slow and surprising.
Acceptance
After fbuild build tests/platform/esp32s3 -e esp32s3, firmware.map and build_info.json exist beside firmware.elf.
Found while investigating ~26 KB of newlib printf bloat on an esp32s3 firmware. Without archive attribution the report didn't even confirm the printf symbols come from libc.a — had to infer from the _r suffix and _dtoa_r signature.
Resolved by #509. Verified: origin/main now emits build_info.json/build_info_.json after successful links, and the merged ESP32 linker change adds -Wl,-Map=<firmware.map> next to firmware.elf with a regression test, so fbuild symbols/bloat can attribute archives/objects/sections for the ESP32 case described here.
Activity
chore(shrink): scaffold module + owo-colors dep (#494, part of #493) (#…
fix(esp32): emit -Wl,-Map=firmware.map at link time (#508, part of #491…
zackees commentedon Jun 8, 2026
Resolved by #509. Verified: origin/main now emits build_info.json/build_info_.json after successful links, and the merged ESP32 linker change adds -Wl,-Map=<firmware.map> next to firmware.elf with a regression test, so fbuild symbols/bloat can attribute archives/objects/sections for the ESP32 case described here.