What is section ".debug_info" in an elf file?

Question

I have an elf file, while analysing the mapfile and elf using elfparser, I saw a section called .Debug_info, which is taking largest memory.

I am compiling for xtensa DSP, using xt-xc++, I haven't used -g option also given -o2 optimization level.

is it possible to remove this for release builds?

Damnatory

Don't know that compiler but does it matter? There usually is a kind of objcopy post build step to create the programmer specific binary anyway which should discard those sections. – Beria

Have you tried using -g0? Or adding --gc-sections parameter to ld? Anyway, it's usually done by -s command or strip tool. – Maleki

@DanM., -g0 and -s option didn't work. – Damnatory

@Damnatory missed that you use custom xtensa compiler. When try just running strip (or xt-strip?) on your final binary. – Maleki

I can not use strip because it removes completesymbol tables. I need to use nm command on this binary. – Damnatory

Have you already seen this?: How debuggers work: Part 3 - Debugging information. – Mecham

@Damnatory Read the man page for strip. It has all kinds of options that allow you to decide what to strip, including stripping only debug information. – Miscarry

Answer 1

section called .debug_info, which is taking largest memory.

Note that this section does not have SHF_ALLOC flag, and therefore does not take any RAM at runtime (it only takes space in the filesystem). Of course if you use ramdisk, then that section still does cost you RAM in the end.

is it possible to remove this for release builds?

Yes: none of the .debug* sections are necessary at runtime, and all of them can be safely stripped.

-g0 and -s option didn't work.

It's likely that you are getting .debug_* sections from libraries that you are linking in, and not from your own code. The -g was present when the libraries were compiled, so building with -g0 doesn't have any effect.

It's surprising that -s didn't work, but maybe your compiler interprets this flag differently.

In any case, you should use strip --strip-debug to get rid of .debug_* sections (note: this does not remove the symbol table).

The best practice is actually to compile all your code with full debug info (-g), save the full debug binary for post-mortem analysis, use strip --strip-debug to make a release binary, and use that binary for actual distribution.

If/when the release binary crashes and leaves a core dump, having (saved) full-debug exactly matching binary greatly improves post-mortem analysis you can do.

Portuguese