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?
build_type = debug.
Is that the case though? I don’t know the internals of the tool but looking at
-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 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
448 bytes of code. When I run it through the PlatformIO’s project inspector, Iget
When re-run the mbed-os-linker-report tool on the ELF file that has been compiled with
build_type = debug, I get
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?
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.
Thank you for your answers!