我编译了一个名为libsuperdmgr.so的动态库。
当我使用gdb调试此lib时，它无法链接到源文件。
如下所示：在第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
这是为什么???我在编译中丢失了什么吗？
答案 0 :(得分：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
了解我如何在编译-g时添加b.c选项并将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.out的链接阶段包含在a.out中，或者必须从libb.so.1.1收集在gdb(1)访问共享库时的运行时。最可能的事情是它是否必须存在于库中，因为它是属于库的数据（您可以在程序构建之后使用不同的共享对象实现和调试信息来改变程序）