0

I use gdb in a cross-compiling environment where I build a linux tree for the target architecture, including lots of shared libraries.

Problem: When I analyze a core dump, gdb finds the paths to my .so files and their symbols, but not their source files.

Host setup:

tree/ <-- Build root

tree/apps/myapp/myapp <--My crashing app

tree/libs/mysharedlib/ <-- Shared libs are built from paths like this and installed in target/

tree/target/ <-- Target build root

tree/target/usr/bin/ <-- My crashing binary goes here

tree/target/lib <-- Some .so:s

tree/target/usr/lib <-- Some more .so:s

Example output:

...
#9 0x2b038cfc in start_thread (arg=0x32dff4d0) at pthread_create.c:302
302 pthread_create.c: No such file or directory.
in pthread_create.c
...

How does gdb know where to search for source files by default?

I know that it's possible to use the 'directory' command in gdb to specify source directories manually, and it works, but I don't want to do that for every shared lib. I want to set the root from which all my stuff was built. When I do live debugging using gdbserver, gdb automatically finds the source for all shared libs, so I would like the same behavior for core files.

Is it only the .c filenames that are specified in the debugging information in the binaries or do they have paths as well? Relative or absolute?

Rumpsteak
  • 95
  • 1
  • 11
  • Whatever path-to-source you give to the compiler, gets written into the object, and then to the .so, to the executable and to the core file. If it's relative, you will have to tell `gdb` where your root is, because it is not specified anywhere. – n. m. could be an AI Feb 13 '13 at 15:09
  • See: http://stackoverflow.com/questions/1103161/gdb-searching-for-source-directories – jxh Feb 13 '13 at 15:18

0 Answers0