How to use gdb to debug a codebase with recursive makefiles

Question

I was given a huge code composed of c++ and QT modules. To compile, I need to run ./configure and then make.

./configure generates several makefiles in directories and subdirectories and running make recursively runs make in directories.

Now I want to change a very small portion of the code in test.h. The executable is in a different folder.

Here is the problem;

# gdb foo
Reading symbols from /xx/yy/zz/foo

(gdb) break ../qq/zz/test.h:53
No source file named ../qq/zz/test.h
Make breakpoint pending on future shared library load? (y or [n])

I have tried absolute path also , but didn't work either.

Then I did this:

(gdb) add-symbol-file  ../qq/zz/someObjFile.o
The address where ../qq/zz/someObjFile.o has been loaded is missing

Then I tried this:

(gdb) symbol-file ../qq/zz/someObjFile.o
Load new symbol table from "../qq/zz/someObjFile.o"? (y or n) y
Reading symbols from  "../qq/zz/someObjFile.o" ...done
(gdb) break test.h:53
Cannot access memory at address 0x20

I have seen some threads answering " Cannot access memory at address" by find the actual memory address, but I think this is not what I need. and I am missing something way simpler.

If it helps:

I'm using GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) and someObjFile.o is the object file generated by makefile in the folder that test.h exists (test.h is included in someObjFile.cpp file)

Any hints is appreciated.

Answer 1

GDB does not load symbols from .so files until you run the program. Also, the files may be referred to by file name, without paths.

Try

b main
r
...
...
# GDB stops
b test.h:57

Also, sometimes on large projects GDB gets confused about line numbers. Try setting breakpoints on a function.

Answer 2

(gdb) break ../qq/zz/test.h:53
No source file named ../qq/zz/test.h
Make breakpoint pending on future shared library load? (y or [n])

This usually means that the code in question was built into a shared library, and you have not loaded that shared library yet.

You should either answer yes to the question GDB is asking, or just run the application once (which will make GDB load and retain debugging symbols for all libraries used in that run), and then set a breakpoing for the second run.

Then I did this:

Furious activity is not a substitute for understanding. Since you lack understanding, it's unlikely that typing various "random" commands into GDB will help you.

Update:

again the same error as "No source file named..."

Well, it's also possible that code in someObjFile.o is not in fact ever loaded into your process. One easy way to confirm this is to put assert(0) in line 53 of test.h. If your program still runs, then (assuming you do not use -DNDEBUG when building) you can be sure that line 53 was in fact never executed.