Interpreting address in core file

Question

I am looking for any references or guidance on how to interpret the addresses in the backtrack of a core file. For e.g. a typical backtrack would look like:

(gdb) where
#0 [0x000012345] in func1 + 123 (a.out + 0xABC)
#1 [0x000034345] in func2 + 567 (a.out + 0xea7)
..

I can compile with -g and get exact line numbers. But the executable in production environment would not have been compiled with -g in which case I get a stack as above.

I would like to know:

what the addresses and offsets [0x000012345], +123 and 0xABC represent, how to interpret them and how to map them to line number in the source code.

Appreciate any help.

Answer 1

On most architectures, it is simply not possible to get good data out of core files without debugging information. Even simple things like stack unwinding will not work. An expert, familiar with the processor architecture and the ABI, will be able to determine many things from it, but it is a cumbersome, manual process.

For the rest of the answer, I assume you are using GCC. If you compile your executable with optimization and -g, GCC will create production-ready binaries with debugging information. Unless there are compiler bugs (which are rare), -g will not affect the generated code. The debugging information consists of data tables on the side (and this causes problems for debugging because the machine code and the original code may be very far apart in aspects such as the execution order of individual statements).

If you do not want to distribute production binaries with debugging information, you should still compile with -g, but remove the debugging information with strip before distributing the binaries, while retaining the unstripped binaries for your own records. When later analyzing a core file, you use these unstripped binaries, rather than the stripped ones you gave away. The in-memory offsets you quote are the same between stripped and unstripped binaries, which is why this works.

For more advanced usage, you could also separate the debugging information using tools such as eu-strip -f, but this does not seem necessary in your case.