c++ - 为什么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) 无法跟随它们，也无法显示您在源代码中的位置。另外，库源是否可用(如果没有，将很难访问源——我知道这个断言很荒谬，但谁知道呢:))o

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

Gdb(1) 有命令指示文件系统中的何处定位模块信息，但如果二进制文件中没有指针来定位源代码点，则无法访问它。

假设您有一个由两个文件组成的程序:a.c 和 b.c

a.c 具有 main() 函数，并且将成为一个普通的应用程序模块。 b.c 将成为一个共享库。

要编译您的应用程序，您可以正常编译 a.c(带有调试信息生成):

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 时包含 -g 选项并将 b.so 链接到 libb.so.1.1.

现在，使用以下命令行链接该程序:

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的链接阶段的a.out中.out 或者必须在运行时当 gdb(1) 访问共享库时从 libb.so.1.1 收集。最有可能的事情是它必须存在于库中，因为它是属于库的数据(您可以在程序构建后为您的程序提供共享对象的不同实现，并且调试信息会有所不同)