ELF is basically the debug format, i.e. contains all the information for debugging (with the respective flags enabled).

Why not doing a post-build step, and convert the ELF output into an *.HEX or *.SREC file ?
These formats contain nothing but the actual code + const data.
Segger's objcopy tool (part of the binutils) could do that, for instance.

> My colleagues need to pass the code to a fuzzing tool.

Assuming you talk about what I know as obfuscator tool, I don't know what want to achieve with that step.
Such a tool tries to hide certain details of the file from third parties, such as path names, libraries, variable and object names.
Commercial Dot-Net projects e.g. use to hide internals through an obfuscator, to impede reverse engineering.

There is no such thing present in HEX or S19 files.
All debug metadata have been stripped in the conversion process.

Nor do *.BIN files, at least those used to contain MCU firmware.
Those files consist of the raw values to program to each Flash cell, without any metadata (which means, not even addresses).
This implies *.BIN files must cover all addresses from the first to the last byte, and thus usually carry a large amount of superfluous data (0xFF) for all the gaps in the text / const data section.

Hello Lef,

Thank you for your inquiry.

As Frank correctly wrote the ELF format does include debug information, while binary and hex only include the image itself.
Instead of using an external tool, the binary or hex output may also be generated directly in ES by using the "Code > Linker > Additional Output Format" project setting.

In case the paths can still be read in the binary, the paths are part of the application itself, e.g. because of exception handling or macros like __FILE__.
Please see here for further information: forum.segger.com/index.php/Thr…cluded-in-hex-image-file/

Best regards,
SebastianB