4

I'm trying to debug a segfault in Android's surfaceflinger daemon on a custom made ARM board. The process crashes before dumping the call stack and register content, including the program counter.

Normally I would've used objdump and searched for the program counter. The problem is that part of the call stack is in a shared library. Without using gdb, how can I correlate the program counter with a line in the source file? That is, can the addresses of shared library instructions be determined without running the program?

Einheri
  • 957
  • 1
  • 9
  • 22

2 Answers2

4

The simplest solution is to load core dump into gdb and use info symbol <program counter address>, see https://stackoverflow.com/a/7648883/72178.

You can also use addr2line but you will have to provide library starting address in parameters to addr2line, see How to map function address to function in *.so files.

ks1322
  • 33,961
  • 14
  • 109
  • 164
1

You need your program (and all the relevant shared libraries) to be compiled with debug information (in DWARF format), e.g. by passing some -g (or -g2 or -g3) flag to the GCC compiler when they are built. Notice that with GCC such a debugging option can be mixed with optimization options like -O2

Then you might use utilities like addr2line, or perhaps libraries like libbacktrace. FWIW, the GCC compiler itself (actually its cc1plus) uses that libbacktrace library to print a useful backtrace on SIGSEGV and other terminating signals (on compiler crashes).

BTW, you could (and probably should) enable core(5) dumping and do a post mortem analysis of it with gdb

Notice that due to ASLR, a shared library is loaded (actually mmap(2)-ed) at some "random" page.

Read Drepper's How to Write Shared Libraries paper.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547