valgrind 堆栈跟踪中缺少符号

发布于 2025-01-05 07:59:45 字数 2159 浏览 4 评论 0原文

我正在使用 valgrind 调试一个通过 dlopen 使用可加载库的二进制文件。 在 debian 稳定版上,堆栈跟踪不包含可加载库内调用的符号。

| | ->11.55% (114,688B) 0x769492C: ???
| | | ->11.55% (114,688B) 0x7697289: ???
| | |   ->11.55% (114,688B) 0x769806F: ???
| | |     ->11.55% (114,688B) 0x419812: myfunc (main.c:1010)

debian stable 上的 Valgrind 工作正常并且符号已正确解析。所以我开始寻找不同的地方。 我在两个系统上都有这些软件包(valgrind 从 stable 更新到 3.7):

ii  valgrind                      1:3.7.0-1+b1
ii  libtool                       2.2.6b-2
ii  gcc                           4:4.4.5-1
ii  binutils                      2.20.1-16

库没有被剥离并包含 debuginfo:

 ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x33ffd210859178c15bb3923c5491e1a1b6065015, not stripped

仔细观察我注意到库的大小不同,在 debian stable 上库稍大一些。与readelf相比,调试信息的大小更大。

  [26] .debug_aranges    PROGBITS        0000000000000000 00a74c 000090 00      0   0  1
  [27] .debug_pubnames   PROGBITS        0000000000000000 00a7dc 000385 00      0   0  1
  [28] .debug_info       PROGBITS        0000000000000000 00ab61 00512f 00      0   0  1
  [29] .debug_abbrev     PROGBITS        0000000000000000 00fc90 0006e2 00      0   0  1
  [30] .debug_line       PROGBITS        0000000000000000 010372 002314 00      0   0  1
  [31] .debug_str        PROGBITS        0000000000000000 012686 0019d3 01  MS  0   0  1
  [32] .debug_loc        PROGBITS        0000000000000000 014059 000f24 00      0   0  1
  [33] .debug_macinfo    PROGBITS        0000000000000000 014f7d 179082 00      0   0  1
  [34] .debug_ranges     PROGBITS        0000000000000000 18dfff 000060 00      0   0  1

这让我觉得在 debian stable 上构建的二进制文件的调试信息部分缺少一些东西。现在我的问题是:二进制文件为什么不同以及如何不同?构建中使用的工具(gcc、libtool、binutils)是相同的,包括编译器/链接器标志和命令(我用 diff 检查了 make 的输出)。

更新: debug_info 部分大小的差异是因为源文件的完整路径也存储在那里并且构建主目录不同。在不稳定/稳定上也有不同的 openssl 版本,它们在 debug_info 部分添加了一些不同的符号。因此 debug_info 大小存在差异。

在调试模式下运行 valgrind (-d -v -v) 显示它在两种情况下都从可加载库中读取符号:

--19837-- Reading syms from /usr/lib/myplugin.so (0x6c62000)

I'm using valgrind to debug a binary which uses loadable libraries via dlopen.
On debian stable the stacktrace does not contain symbols for calls inside the loadable lib.

| | ->11.55% (114,688B) 0x769492C: ???
| | | ->11.55% (114,688B) 0x7697289: ???
| | |   ->11.55% (114,688B) 0x769806F: ???
| | |     ->11.55% (114,688B) 0x419812: myfunc (main.c:1010)

Valgrind on debian unstable works fine and the symbols are properly resolved. So I started looking what is different.
I have these packages on both systems (valgrind was updated to 3.7 from unstable):

ii  valgrind                      1:3.7.0-1+b1
ii  libtool                       2.2.6b-2
ii  gcc                           4:4.4.5-1
ii  binutils                      2.20.1-16

The libs are not stripped and contain debuginfo:

 ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x33ffd210859178c15bb3923c5491e1a1b6065015, not stripped

Looking closer I noticed that the size of the libraries are different, on debian unstable the lib is slightly bigger. Comparing them with readelf, the size of the debug info is bigger.

  [26] .debug_aranges    PROGBITS        0000000000000000 00a74c 000090 00      0   0  1
  [27] .debug_pubnames   PROGBITS        0000000000000000 00a7dc 000385 00      0   0  1
  [28] .debug_info       PROGBITS        0000000000000000 00ab61 00512f 00      0   0  1
  [29] .debug_abbrev     PROGBITS        0000000000000000 00fc90 0006e2 00      0   0  1
  [30] .debug_line       PROGBITS        0000000000000000 010372 002314 00      0   0  1
  [31] .debug_str        PROGBITS        0000000000000000 012686 0019d3 01  MS  0   0  1
  [32] .debug_loc        PROGBITS        0000000000000000 014059 000f24 00      0   0  1
  [33] .debug_macinfo    PROGBITS        0000000000000000 014f7d 179082 00      0   0  1
  [34] .debug_ranges     PROGBITS        0000000000000000 18dfff 000060 00      0   0  1

This makes me think that something is missing from the debug info section from the binaries built on debian stable. Now my question is: why and how are the binaries different? The tools (gcc, libtool, binutils) used in the build are the same, including the compiler/linker flags and commands (I checked with diff on make's output).

Update:
The debug_info section size difference came from the fact that the full path of the source file is stored there as well and the build home was different. Also there are different openssl versions on unstable/stable which added some different symbols to the debug_info section. Hence the difference in debug_info size.

Running valgrind in debug mode (-d -v -v) shows that it reads symbols from the loadable lib in both cases:

--19837-- Reading syms from /usr/lib/myplugin.so (0x6c62000)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

差↓一点笑了 2025-01-12 07:59:45

如果您使用 dlopen 作为可加载库,则它很可能在程序终止之前被卸载。因此 Valgrind 无法解析其符号。尽量避免在此库上调用dlclose。请参阅http://valgrind.org/docs/manual/faq.html#faq .无帮助了解更多信息。

If you are using dlopen for the loadable library, chances are that it was unloaded before the program terminates. Therefore Valgrind is unable to resolve its symbols. Try to avoid calling dlclose on this library. See http://valgrind.org/docs/manual/faq.html#faq.unhelpful for more information.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文