为什么gdb找不到源文件 [英] why gdb cannot find source file

问题描述

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

 ＃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）（）从/home/shawu/infra/wqsim/arch/x86_64_Linux/wqsim_shawu/infra/libsuperdmgr.so 
＃2 0x00007fffc9ba6eb0在NIODataStorageTester :: Initialize（int，char const *，WQSim_Config :: Element const *）（）
从/home/shawu/infra/wqsim/arch/x86_64_Linux/wqsim_shawu/infra/libsuperdmgr.so 
＃3在wqSim_DataRegistry :: Handle中的0x00007ffff543f527（这是< value optimized out>，handle =< value optimized out>，cfg =< value optimized out>）
 at wqsim / framework / WQSim_dataregistry.cc：618 $ b wqsim / framework / WQSim_modulehandler.cc中的WQSim_ModuleHandler :: LoadModules（this =< value optimized out>）中的$ b＃4 0x00007ffff588eea1：125 
＃5 0x00007ffff7593586 in wqsim_main_init（argc =< value optimized out> argv =< value optimized out>）at wqsim / modules / WQSim_main.cc：1016 
  

???在编译时丢失了什么？

解决方案

最可能的原因是...共享库<具有调试支持？如果没有，你没有二进制代码中的指针到库中的源点，因此 gdb（1）他们并不能告诉你在源代码中的位置。另外，是可用的库源（如果不是，将很难访问源---我知道这个断言是可笑的，但谁知道:)）

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

Gdb（1）有指示在文件系统中定位模块信息的命令，但如果你没有指针

假设你有一个由两个文件组成的程序： ac 和 bc

ac c $ c> main（）函数，并将成为正常的应用程序模块。
bc 将是一个共享库。

调试信息生成）：

  cc -g -c ac -o ao 
  

要将 bc 编译为共享对象，您可以使用：

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

但这不是我们的最终可加载的共享对象。现在构造共享对象：

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

看看我如何在编译 bc 中链接 b.so / code>到 libb.so.1.1 。

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

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

和 a.out 将具有从 ao 和 b.so.1.1 （但您需要在 b.so.1.1 如果您想要使用它）

注意

我不知道如果 b.so.1.1 的调试信息在 a.out 中包含在 a.out 或者必须在运行时从 libb.so.1.1 中收集 gdb （1）访问共享库。最可能的事情，如果它必须存在于库中，因为它是属于库的数据（你可以在程序构建之后，用不同的共享对象实现馈送你的程序，调试信息会有所不同） p>

I compiled a dynamic lib named libsuperdmgr.so. When I debug this lib using gdb, it cannot link to the source file. Like the following: In frame 3 and 4 it can show the detailed line of source file, but when it come to my lib in frame 2 and frame 1, it does not show the detailed 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??? Do I lost something in compile?

解决方案

The most probable reason is... Was the shared library compiled/linked with debugging support? if not, you don't have the pointers in the binary code to the source points in the library, so gdb(1) cannot follow them and cannot show you where in the source code you are. Also, are the library sources available (if not, it will be difficult to access the source ---i know this assertion is ridiculous, but who knows :))o

If you can, use -g option recompiling the shared object library and link it also with that option to conserve the debug info in the final shared object.

Gdb(1) has commands to indicate where in the filesystem to locate module info, but if you don't have the pointers in the binary to locate the source code points you cannot access it.

Suppose you have a program made of two files: a.c and b.c

a.c has the main() function and is going to be a normal application module. b.c is going to be a shared library.

To compile your application you compile a.c normally (with debug info generation):

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

To compile b.c as a shared object you use:

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

but this is not our final loadable shared object. We have only compiled it to an object file (sorry for the conflicting suffix) Now construct the shared object:

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

see how I have included -g option in compiling b.c and linking b.so into libb.so.1.1.

Now, link the program with the following command line:

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

and a.out will have the debug info received from a.o and b.so.1.1 (but you need to have it in b.so.1.1 if you want to be able to use it)

Note

I don't know at this moment if the debug info of b.so.1.1 is included into a.out in the linking phase of a.out or it must be gathered from the libb.so.1.1 at run time when gdb(1) accesses the shared library. The most probable thing if for it to have to be present in the library, as it is data belonging to the library (you can after program construction feed your program with a different implementation of the shared object and the debugging info will vary)

这篇关于为什么gdb找不到源文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！