为什么gdb找不到源文件

Question

我编译了一个名为libsuperdmgr.so的动态库。 当我使用gdb调试这个库时，它不能链接到源文件。 如下所示：在第3帧和第4帧中，它可以显示源文件的详细行，但是当它在第2帧和第1帧的我的lib中时，它不显示详细的行号。

#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 

这是为什么？我在编译时丢失了什么？

Answer 1

最可能的原因是......共享库编译/链接调试支持？如果没有，您没有二进制代码指向库中源点的指针，因此gdb(1)无法关注它们，也无法向您显示源代码中的位置。另外，是否有图书馆的资源可用（如果没有，这将是很难访问的来源---我知道这种说法是荒谬的，但谁知道:)）

如果可以，请使用-g选项重新编译共享对象库并将其与该选项链接以保存最终共享对象中的调试信息。

Gdb(1)有指示在文件系统中的哪个位置查找模块信息，但是如果您没有二进制指针来查找源代码点，则无法访问它。

假设你已经做了两个文件的程序：a.c和b.c

a.c有main()功能，将是一个正常的应用模块。 b.c将成为共享库。

要编译应用程序编译AC正常（与调试信息代）：

cc -g -c a.c -o a.o 

编译b.c你使用一个共享对象：

cc -fPIC -g -c b.c -o b.so 

但这并不是我们的最终加载共享对象。我们只是它编译成目标文件（抱歉冲突后缀）现在构建的共享对象：

cc -g -o libb.so.1.1 -shared -Wl,-soname=b.so.1 b.so 

怎么看我已经包含在编制b.c和链接b.so到libb.so.1.1-g选项。

现在，用以下命令行链接程序：

cc -o a.out -g a.o libb.so.1.1 

和a.out将有来自a.o和b.so.1.1（收到的调试信息，但你必须有它在b.so.1.1，如果你想能够使用它）

注

我没有在这一刻知道的b.so.1.1调试信息被纳入a.out在01链接阶段，或者在gdb(1)访问共享库时，必须在运行时从libb.so.1.1中收集。最可能的情况是它必须存在于库中，因为它是属于库的数据（你可以在程序构建之后用不同的共享对象实现程序并且调试信息会有所不同）