I have a python executable: pyExec.py. This program utilizes a C/C shared library: abc.so. This abc library requires another C/C library: xyz. Once xyz is built, it generates multiple static library files and one shared library file, which are then used to build abc. I want to investigate a function ffn which is present in one of the source files for xyz.

None of these libraries throw any error during the compilation. The error I am investigating occurs when I run a particular function in pyExec.py. So far, this error has been traced back to ffn. However, to proceed further, I would like to use a debugger.

I tried this answer, along with a few variants of it. I tried setting break points in the source files of both xyz and abc using both line numbers and function names, just to test things out. The debugger, gdb, does ask if the break point is pending on a future shared library load to which I answer yes. But unfortunately the break point is ignored when I run the (python) program. The debugger is called as shown here.

1. Is gdb the best tool for such an investigation?
2. What could be the best overall approach in this context?
3. Can static libraries be investigated with this approach?

CodePudding user response：

1. gdb should be very capable but you need to be aware of versions. I was recently using clang to compile and gdb to debug and hit this exact case. Ends up clang supports more debug formats. When I switched to lldb (clang's debugger) all symbols came clean. Try lldb and see what happens.

2. Unit tests. They help set up edge cases. Try to eliminate all the environment complexity and isolate in the smallest reproducible example you can.

3. Yes, absolutely. You need to be sure you are compiling with debug information though.