尝试使用gdb调试使用libtool构建的软件包的测试程序时，我看到一个奇怪的问题。如果我运行libtool --mode=execute gdb .libs/libfoo.so并要求它列出某些函数list Bar::Baz的源，我将按预期获得源代码。如果我运行libtool --mode=execute gdb binary，则可以破坏Bar::Baz()，并在堆栈跟踪中查看其参数，但是没有任何源文件或行号，如下所示:
#7 0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
^^^^^^^^^^^ <--- debug symbols are present!
同样，如果在调试可执行文件时尝试使用
list Bar::Baz，我会得到No line number known for 'Bar::Baz'.
我已经确认该二进制文件与
-g链接，并且可以列出其main函数，因此我知道存在一些调试信息。当我说
info sources时，我获得了构建库的文件的完整列表，并带有正确的绝对路径。当我说info shared时，我会获得列出到目标文件的正确路径，并在Yes列中带有Syms。还有其他想法可能出什么问题，以及如何解决？
编辑1:偶然，我在有问题的库上运行了
objdump -g，并得到以下输出:/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information
这是令人惊讶的，因为
objdump -h(我曾尝试运行)列出了许多.debug_*节。 objdump手册也建议使用readelf -w，这似乎可以打印大量信息。不过，我需要仔细研究一下它实际上提供了什么。编辑2:因此，
readelf -w产生了一些启示。无论出于何种原因，共享对象文件似乎都不包含来自链接到该对象的绝大多数对象的调试信息。根据Makefile文件，可能没有将实际上将对象收集到共享库中的命令传递给-g，因此信息无法正确传播。有趣的是，这可以在我们所有其他配置上起作用(具有完整的调试信息)，包括x86_64上的相同编译器版本(相对于当前的x86)。编辑3:实际上，在修改过的Makefile上进行了完全重建，并在LDFLAGS上添加了-g，这没什么区别。现在，我感觉好极了。
最佳答案
这是对一个旧问题的解答，但您的问题与我的相匹配，但所有解决方案均无效。这是对我有用的东西。
将CFLAGS -g更改为“-g -gstabs”。
objdump无法识别侏儒风格的调试信息。 -gstabs将此格式更改为可与objdump -g和objdump -S以及我的调试器一起使用的格式。
希望能帮助到你。
注意:对我来说，我正在构建一个Linux内核。所做的更改是在Linux内核的Makefile中进行的。
关于gdb - 整个程序中库的调试符号缺少行号，但不是单独的，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6770393/