整个程序中库的调试符号缺少行号，但其本身没有
当尝试使用 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!
同样，如果我在调试可执行文件时尝试列出 Bar::Baz，我会
No line number known for 'Bar::Baz'.
确认二进制文件已与 -g 链接code>，我可以列出它的 main 函数，所以我知道存在一些调试信息。
当我说信息源时，我会得到构建库的文件的完整列表，以及正确的绝对路径。当我说info共享时，我得到了列出的目标文件的正确路径，并且Syms列中显示Yes。
还有什么进一步的想法可能会出现问题以及如何解决它？
编辑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 （我曾尝试过run) 列出了一堆 .debug_* 部分。 objdump 手册也建议使用 readelf -w ，这似乎会打印大量信息。不过，我需要看看它实际上提供了什么。
编辑2：所以，readelf -w 产生了一些启示。无论出于何种原因，共享对象文件似乎不包含来自绝大多数任何链接到其中的对象的调试信息。根据 Makefile，实际将对象收集到共享库中的命令可能未传递 -g，因此信息未正确传播。有趣的是，这在我们所有其他配置上都有效（具有完整的调试信息），包括 x86_64 上的相同编译器版本（相对于当前的 x86）。
编辑3：实际上使用修改后的Makefile进行了完全重建，并在LDFLAGS上添加了-g，这没有什么区别。现在我真的很困惑。
I'm seeing an odd issue when trying to use gdb to debug a test program for a package built with libtool. If I run libtool --mode=execute gdb .libs/libfoo.so and ask it to list the source of some function list Bar::Baz, I get the source code as expected. If I run libtool --mode=execute gdb binary, I can break in Bar::Baz(), and see its arguments in a stack trace, but I get no source file or line numbers, like so:
#7 0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
^^^^^^^^^^^ <--- debug symbols are present!
Similarly, if I try to list Bar::Baz when debugging the executable, I get
No line number known for 'Bar::Baz'.
I have confirmed that the binary is linked with -g, and I can list its main function, so I know some of the debug information is present are present.
When I say info sources, I get a full listing of the files from which the library is built, with correct absolute paths. When I say info shared, I get the correct path listed to the object file, with a Yes in the Syms column.
Any further ideas what could be going wrong, and how to fix it?
Edit 1: By accident, I ran objdump -g on the offending library, and got the following output:
/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information
This is surprising, since objdump -h (what I had tried to run) lists a bunch of .debug_* sections. The objdump manual suggests readelf -w as well, and that seems to print a huge pile of information. I need to go look through at what it actually provides, though.
Edit 2: So, readelf -w has produced some enlightenment. For whatever reason, the shared object file doesn't seem to contain the debugging information from the vast majority any of the objects linked into it. Based on the Makefiles, it's possible that the command that actually gathers up the objects into the shared library isn't passed -g, and so that information isn't properly propagated. The funny thing is that this works (has full debug information) on all our other configurations, including the same compiler version on x86_64 (versus the present x86).
Edit 3: Actually went through a full rebuild with the modified Makefile with -g added on the LDFLAGS, and it made no difference. Now I'm well and truly baffled.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个老问题的答案，但你的问题与我的问题相符，但没有一个解决方案有效。这对我有用。
将 CFLAGS -g 更改为“-g -gstabs”。
objdump 无法识别矮人风格的调试信息。 -gstabs 将此格式更改为可与 objdump -g 和 objdump -S 以及我的调试器一起使用的格式。
希望有帮助。
注意：对我来说，我正在构建一个 Linux 内核。此更改是在 Linux 内核的 Makefile 中进行的。
This is an answer to an old question, but your problem matched mine, but none of the solutions worked. Here is what worked for me.
Change CFLAGS -g to "-g -gstabs".
objdump was not recognizing the dwarf style debug information. -gstabs changes this format to one that works with objdump -g and objdump -S and my debugger.
Hope it helps.
NOTE: For me, I was building a linux kernel. This change was make in the linux kernel's Makefile.
您的第一个困惑点：
Bar::Baz(Qux*, Quux*)确实不暗示存在调试符号（事实上暗示它们是不存在）。调试器仅对函数名称进行解析。如果调试符号确实存在，您会看到
Bar::Baz(Qux* qux = 0x12..., Quux* quux = 0x234...)至于真正的问题，我怀疑该符号是在某些其他库中定义的，该库
libfoo.so之前出现在二进制文件的链接行上，并且（运行时加载程序将引用绑定到
Bar::Baz()到它看到的第一个定义。）如果您在第 7 帧中打印
ip，则执行info symbol，我怀疑你会“啊哈！”片刻。编辑：您的更新使您的问题自相矛盾。 AFAICT，
gdb在执行时可以看到调试符号libtool --mode=execute gdb .libs/libfoo.solibtool --mode=execute gdb bin时，完全相同的
.libs/libfoo.oreadelf -w在.libs/libfoo.o< 中看不到调试符号/code>上述陈述至少有一项可能是错误的。
如果它们都是真的，那么您可能会遇到一个奇怪的
GDB和readelfbug（一个错误可能存在，两个同时出现错误）有点不太可能）。另请注意，将
-g添加到LDFLAGS通常是错误的做法。您是否想将其添加到CXXFLAGS中？Your first point of confusion:
Bar::Baz(Qux*, Quux*)does not imply that debug symbols are present (and in fact implies that they are not present).The debugger merely demangles the function name. If the debug symbols were in fact present, you'd see
Bar::Baz(Qux* qux = 0x12..., Quux* quux = 0x234...)As for the real problem, I suspect that the symbol is defined in some other library, which
libfoo.sodoes, and(The runtime loader will bind the reference to
Bar::Baz()to the first definition it sees.)If you print
ipin frame #7, then doinfo symbol <value-just-printed>, I suspect you'll have an "Aha!" moment.EDIT: Your update made your question self-inconsistent. AFAICT,
gdbcan see debug symbols when you executelibtool --mode=execute gdb .libs/libfoo.solibtool --mode=execute gdb binaryexact same
.libs/libfoo.oreadelf -wdoesn't see debug symbols in.libs/libfoo.oAt least one of the above statements is likely false.
If they are all really true, you probably have a weird
GDBandreadelfbug (a bug in one is possible, a simultaneous bug in both is somewhat unlikely).Also note that adding
-gtoLDFLAGSis generally the wrong thing to do. Did you mean to add it toCXXFLAGSinstead?有些事情让我想知道当你遇到时
show language的输出是什么问题。如果不是
c++，也许需要设置语言c++？Something made me wonder what the output of
show languageis when you are experiencingproblems. If its not
c++, maybeset language c++is necessary?