Inspect Memory: is it possible with a release build?

1

The flash memory consumption of the debug build is significantly more than that of the release build, mostly because different optimization. As far as I see, the memory inspection looks at the debug build. Looking at my longest function, I reduced its memory footprint by 2.6 kBytes, just by declaring something constexpr. The overall size of the release build did not change at all. Most probably, the calls were optimized out in release, anyway.

My aim is to reduce the flash footprint of the release build. Would it be possible to run the inspection upon the release build? Alternatively, can I specify the same optimization level for the debug build as for the release build?

platform: atmelsam
framework: arduino
board: due
toolchain-gccarmnoneeabi@1.90301.200702

2

See build_type = debug.

Is that the case though? I don’t know the internals of the tool but looking at -Og or -O0 compiled binaries / ELF files wouldn’t be representative of the release binary in a lot of cases, more as a “general landmark”, I agree. I’m sure @ivankravets knows how it works internally.

Btw, you can also set GCC to create a .map file (Generate a .map file - #6 by ivankravets) from which the sizes can be equally analyzed, using e.g. Amap | Sergey Sikorskiy or GitHub - bmwcarit/Emma: Emma Memory and Mapfile Analyser. (Repo marked private after security audit. Contact Marian Kneer for details) or GitHub - ARMmbed/mbed-os-linker-report: Post-processing of linker output to calculate and visualize memory usage for elf-sections.

The latter even just takes an .ELF file and generates an interactive HTML page for exploration. When I e.g. use the stm32cube-hal-blink project and run the release-binary through that, using

python elfsize.py -b -i C:\Users\<user>\Documents\Platformio\Projects\forum_test\.pio\build\nucleo_f103rb\firmware.elf

(while having a GCC-ARM toolchain in my PATH), I get, e.g. regarding the HAL_GPIO_Init() function

grafik
grafik1471Ă—940 91.3 KB

448 bytes of code. When I run it through the PlatformIO’s project inspector, Iget

grafik
grafik1091Ă—404 20.2 KB

472 bytes.

When re-run the mbed-os-linker-report tool on the ELF file that has been compiled with build_type = debug, I get

grafik
grafik941Ă—896 137 KB

Yeah indeed 472 bytes as well. So it really does look at the debug output.

Maybe that can be improved or at least a setting can be provided to analyze the release build, e.g. with the help of the .map file if certain symbol / debug information isn’t in the ELF file anymore?

1 Like
3

At the moment the “Project Inspector” only works with ELF files compiled in debug mode. The main reason is that we need additional information (like symbol locations) to prepare a comprehensive report. A map file is a potential workaround, but we support so many different platforms with different toolchain versions that makes parsing map files a pretty complicated task.

1 Like
4

Thank you for your answers!