FAQ

No. The CLI and GitHub Action read the section and symbol table on your machine and send only that metadata, so the compiled binary never leaves your runner. In the web app the file is held in memory for the request and discarded once the analysis returns. Nothing writes the binary to disk or a database.

What we keep is the result: section and symbol sizes, totals, and warnings, tied to your account so history and diffs work. The metadata is the same data readelf -S and nm already print. See the privacy policy.

The tools count different things. memprobe sums the allocated sections that occupy space in the file, which is the code and data programmed into flash. arm-none-eabi-size sorts bytes into its own text, data, and bss buckets. esptool reports the final flashable image, which adds the bootloader, partition table, and padding on top of your code.

So memprobe measures your firmware; the flashing tools measure the packaged image around it.

Source mapping comes from DWARF debug info. If a symbol has no file, the build dropped -g or the debug sections were stripped. Build with debug info to get per-symbol source mapping; it lives in the ELF, not in the flashed image, so it costs nothing on the device. memprobe also reads STT_FILE markers, which cover many local symbols even without full DWARF.

Yes, with less detail. Section sizes and flash/RAM totals come from the section headers and always work. The symbol table and source mapping need symbols, so a stripped binary gives you the size breakdown but not the per-symbol view.

Those features need DWARF call-site and debug data, which only exists when you build with -g. Release builds often drop it. Add -g to the build you analyze; the flashed image does not change, since debug sections are not loaded onto the device.

ELF executables (.elf) and Arm's .axf, from any toolchain: GCC, Clang, IAR, Keil, ESP-IDF, Zephyr, PlatformIO, Rust. Raw .bin and .hex images and linker .map files do not carry section and symbol data, so they are not supported. To set part capacity from a linker script, run memprobe init --from-ld <script.ld>.

RAM is the bytes your program occupies at runtime: initialized data, zero-initialized .bss, and similar writable sections. It does not include heap or stack growth, which are runtime behavior, not static size. For stack figures, use the stack-usage analysis.

Every analyze counts against the monthly limit and saves a build. check and diff run the gate without saving a build. A failed analysis is refunded.

Yes. The CLI honors MEMPROBE_SERVER (or config set --server) to target a different backend. Running the analysis backend on-prem is a Teams conversation: contact us.

Email [email protected]. If a flash or RAM number looks wrong, include the toolchain and target and we will look into it.