size

What it does

size is a GNU binutils tool that reports the size of the standard sections — text (code), data (initialized variables), and bss (uninitialized variables) — inside a compiled object file, library, or executable, along with a decimal and hexadecimal grand total. It's primarily used to understand how much storage (flash/disk) and runtime memory (RAM) a binary will require, which is especially important on resource-constrained targets like embedded systems and microcontrollers.

Beginner examples

• size myprogram — show text/data/bss totals in the default Berkeley format
• size *.o — show sizes for every object file matching the glob, one line per file
• size -A myprogram — show a detailed per-section breakdown (System V format)
• size -x myprogram — show the totals in hexadecimal instead of decimal

size myprogram

Advanced examples

• Compare sizes across several binaries with a combined total: size -t app1 app2 app3
• Inspect every named section (including .rodata, .debug_info, etc.), not just the three summary categories: size -A -x firmware.elf
• Track binary growth over time in a build script by capturing size output after each build and diffing it against a previous run.
• Check the size impact of enabling debug symbols by comparing size app before and after building with -g.

size -A -d firmware.elf

Common mistakes

• Confusing size's reported totals with the file's size on disk — the file also contains headers, symbol tables, and debug info that size's text/data/bss summary doesn't include (use ls -lh or du -h for actual file size).
• Forgetting that bss doesn't occupy space in the file itself, only at runtime — a large uninitialized array bloats runtime RAM usage but not disk size.
• Ignoring size output entirely on embedded projects until a build unexpectedly overflows flash or RAM — it's more useful checked continuously during development.
• Comparing size output between a stripped and unstripped binary and expecting text/data/bss to differ — stripping removes symbol tables and debug info, not the actual code/data/bss sections size reports on.

Tips

• Use -A when you need to see individual sections like .rodata or .debug_info rather than just the three summary buckets from the default Berkeley format.
• On embedded targets, watch the dec total against your chip's flash and RAM limits after every significant change — size is a fast way to catch overflow before flashing hardware.
• Combine size with a CI step that fails the build if text+data exceeds a defined budget, to catch binary bloat regressions automatically.

Best practices

• Check size output as part of the build for any project targeting constrained hardware (microcontrollers, bootloaders) rather than discovering overflow at flash time.
• Use -A for detailed section-by-section review when optimizing for size, since the Berkeley summary can hide which specific section (e.g. .rodata vs .text) is actually growing.
• Track size output over time (e.g. in CI logs) to catch gradual binary bloat before it becomes a problem.

Real-world use cases

• Verifying a firmware image still fits within a microcontroller's flash and RAM budget after adding a new feature.
• Comparing the memory footprint of two implementations of the same function to choose the leaner one for a size-constrained target.
• Diagnosing unexpectedly large RAM usage by checking whether it's coming from bss (uninitialized globals) rather than data or text.
• Tracking binary size growth release-over-release as part of a size-budget CI check.

Common interview questions

• What do the text, data, and bss sections represent? text is compiled machine code, data is initialized global/static variables stored in the file, and bss is uninitialized global/static variables that occupy runtime memory but aren't stored in the file (the loader zero-fills them at load time).
• Why is size especially useful in embedded development? Because flash and RAM are both tightly limited on microcontrollers, and size gives a fast way to check whether a build fits its hardware budget before flashing.
• Does a smaller bss section reduce the file size on disk? No — bss doesn't take file space at all regardless of size, since it's zero-filled at load time; it only affects runtime RAM usage.
• How would you get a detailed, per-section view instead of the summary totals? Use size -A (System V format), which lists every named section individually instead of just the text/data/bss summary.