Why gdb cannot find the source file
I have compiled a dynamic lib named libsuperdmgr.so
. When I debug this library using gdb, it cannot reference the original file. As in the following: in frames 3 and 4, it can display the verbose line of the source file, but when it gets to my library in frame 2 and in frame 1, it doesn't show the verbose line number.
#0 std::operator<< <char, std::char_traits<char>, std::allocator<char> > (__os=..., __str=...)
at /root/gcc/gcc-4.5.1/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2605
#1 0x00007fffc9ba67db in DmgrWrapper::AddDataStorage(NIODataStorage*, int) () from /home/shawu/infra/wqsim/arch/x86_64_Linux/wqsim_shawu/infra/libsuperdmgr.so
#2 0x00007fffc9ba6eb0 in NIODataStorageTester::Initialize(int, char const*, WQSim_Config::Element const*) ()
from /home/shawu/infra/wqsim/arch/x86_64_Linux/wqsim_shawu/infra/libsuperdmgr.so
#3 0x00007ffff543f527 in WQSim_DataRegistry::Handle (this=<value optimized out>, handle=<value optimized out>, cfg=<value optimized out>)
at wqsim/framework/WQSim_dataregistry.cc:618
#4 0x00007ffff588eea1 in WQSim_ModuleHandler::LoadModules (this=<value optimized out>) at wqsim/framework/WQSim_modulehandler.cc:125
#5 0x00007ffff7593586 in wqsim_main_init (argc=<value optimized out>, argv=<value optimized out>) at wqsim/modules/WQSim_main.cc:1016
Why is this??? Am I missing something in compilation?
source to share
Most likely cause ... Was the split library compiled / linked with debugging support? if not, you don't have pointers in binary to the source points in the library, so gdb(1)
you can't follow them, and can't show you where you are in the source. Also, library sources are available (if not, it will be difficult to access the source --- I know this statement is funny, but who knows :)) o
If you can, use the option -g
to recompile the shared object library and link it with this option to preserve the debug information in the final shared object.
gdb(1)
has commands that tell you where in the filesystem to find the module information, but if you don't have binary pointers to find the source code points, you can't access it.
Suppose you have a program that consists of two files: a.c
andb.c
a.c
has function main()
and will be a normal application module.
b.c
will be a shared library.
To compile your application, you usually compile ac (with generating debug info):
cc -g -c a.c -o a.o
To compile b.c
as a shared object you are using:
cc -fPIC -g -c b.c -o b.so
but this is not our final loadable shared object. We only compiled it into an object file (sorry for the conflicting suffix). Now create a shared object:
cc -g -o libb.so.1.1 -shared -Wl,-soname=b.so.1 b.so
let's see how I included the parameter -g
in compilation b.c
and binding b.so
to libb.so.1.1
.
Now connect the program with the following command line:
cc -o a.out -g a.o libb.so.1.1
and a.out
will have debug information from a.o
and b.so.1.1
(but you need to have it in b.so.1.1
if you want to use it)
Note
I don't know at the moment if debug information is b.so.1.1
included in the a.out
linking phase a.out
or needs to be collected from libb.so.1.1
runtime when gdb(1)
accessing the shared library. Most likely thing if it should be in the library, since this is data owned by the library (after creating the program, you can combine your program with another implementation of the shared object and the debug information will change)
source to share