How to analyze and debug gdb core with no symbols, using registers and raw stack

At a customer place a third party software has crashed. The process and the libraries are stripped (no symbols), the call stack does not give any useful information. All that I have is registers which may not be corrupted. This third party code has been written is C.

Now, I have used gdb till now to debug simpler issues. But this one is a bit complicated. I think register and raw stack information may be used to corelate where the crash occurred and I require help on this aspect.

It may not be possible to deploy a non-stripped binary at customer site, nor would it be possible to do inhouse crash reproduction. Also, I am not familiar with this third party code.

Also I require pointers/sites/documents for the following:

1) ELF and various section headers.

2) How to create a symbol file (during compilation) for a library and a process.

3) How to tell gdb to read symbols from a symbol file开发者_JAVA百科.

One thing we should be able to do is to open you core file against a non-stripped/with-symbols version of your process. As long as the compilation process (compiler, optimization flags, etc.) is the same and you just keep all these debugging information, GDB should be able to provide you with all the information you can expect from a core.

gdb [options] executable-file core-file

To compile your process with the debugging information (symbols and dwarfs for lines, types, ...), you need to add -g in your compiler flags. The same applies for your custom libraries.

For the system libraries, it might be conviant sometime (not always), modern Linux distributions (at least Fedora) directly provide them to gdb.