c - gcc -g vs not -g and strip vs not strip, performance and memory usage?

Question

If binary file size is not an issue, are there any drawbacks using -g and not strip binaries that are to be run in a performance critical environment? I have a lot of disk space but the binary is cpu intensive and uses a lot of memory. The binary is loaded once and is alive for several hours.

EDIT:

The reason why I want to use binaries with debugging information is to generate useful core dumps in case of segmentation faults.

question from:https://stackoverflow.com/questions/5936181/gcc-g-vs-not-g-and-strip-vs-not-strip-performance-and-memory-usage

Answer 1

The ELF loader loads segments, not sections; the mapping from sections to segments is determined by the linker script used for building the executable.

The default linker script does not map debug sections to any segment, so this is omitted.

Symbol information comes in two flavours: static symbols are processed out-of-band and never stored as section data; dynamic symbol tables are generated by the linker and added to a special segment that is loaded along with the executable, as it needs to be accessible to the dynamic linker. The strip command only removes the static symbols, which are never referenced in a segment anyway.

So, you can use full debug information through the entire process, and this will not affect the size of the executable image in RAM, as it is not loaded. This also means that the information is not included in core dumps, so this does not give you any benefit here either.

The objcopy utility has a special option to copy only the debug information, so you can generate a second ELF file containing this information and use stripped binaries; when analyzing the core dump, you can then load both files into the debugger:

objcopy --only-keep-debug myprogram myprogram.debug
strip myprogram