call stack for code compiled without -g option (gcc compiler)

How do I analyze the core dump (开发者_如何学Gousing gdb) which is not compiled with -g GCC option ?

Generate a map file. The map file will tell you the address that each function starts at (as an offset from the start of the exe so you will need to know the base address its loaded too). So you then look at the instruction pointer and look up where it falls in the map file. This gives you a good idea of the location in a given function.

Manually unwinding a stack is a bit of a black art, however, as you have no idea what optimisations the compiler has performed. When you know, roughly, where you are in the code you can generally work out what ought to be on the stack and scan through memory to find the return pointer. its quite involved however. You effectively spend a lot of time reading memory data and looking for numbers that look like memory addresses and then checking that to see if its logical. Its perfectly doable and I, and I'm sure many others, have done it lots of times :)

With ELF binaries it is possible to separate the debug symbols into a separate file. Quoting from objcopy man pages:

1. Link the executable as normal (using the -g flag). Assuming that is is called foo then...
2. Run objcopy --only-keep-debug foo foo.dbg to create a file containing the debugging info.
3. Run objcopy --strip-debug foo to create a stripped executable.
4. Run objcopy --add-gnu-debuglink=foo.dbg foo to add a link to the debugging info into the stripped executable.

that should not be a problem , you can compile the source again with -g option and pass gdb the core and the new compiled debug binary, it should work without any problem.

BTW You can generate a map file with the below command in gcc

gcc -Wl,-Map=system.map file.c

The above line should generate the map file system.map, Once the map file is generated you can map the address as mentioned above but i am not sure how are you going to map the share library, this is very difficult