如何使用调试版本的 libc
Posted
技术标签:
【中文标题】如何使用调试版本的 libc【英文标题】:How to use debug version of libc 【发布时间】:2012-04-17 12:35:16 【问题描述】:简短的问题:
如何让 gdb 使用 libc
的调试符号?
加长版:
我正在用 gdb 调试一个程序,我想查看libc
使用的 futex 的信息。但是,在调试过程中的某些时候,我会得到如下输出:
Catchpoint 2 (call to syscall futex), 0x00007ffff772b73e in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff772b73e in ?? () from /lib/libc.so.6
#1 0x00007ffff767fb90 in ?? () from /lib/libc.so.6
#2 0x00007ffff767a4c0 in vfprintf () from /lib/libc.so.6
#3 0x00007ffff768565a in printf () from /lib/libc.so.6
....
当我在 gdb 中的断点处运行 info sharedlibrary
时,我看到:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7dddaf0 0x00007ffff7df6704 Yes (*) /lib64/ld-linux-x86-64.so.2
0x00007ffff7bc53e0 0x00007ffff7bd1388 Yes (*) /lib/libpthread.so.0
0x00007ffff79ba190 0x00007ffff79bd7d8 Yes (*) /lib/librt.so.1
0x00007ffff76538c0 0x00007ffff7766c60 Yes (*) /lib/libc.so.6
0x00007ffff6c1fd80 0x00007ffff6c303c8 Yes (*) /lib/libgcc_s.so.1
(*): Shared library is missing debugging information.
当我运行ldd
时,我看到了:
linux-vdso.so.1 => (0x00007ffff7fde000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffff7dbf000)
librt.so.1 => /lib/librt.so.1 (0x00007ffff7bb6000)
libc.so.6 => /lib/libc.so.6 (0x00007ffff7833000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fdf000)
我使用的是 Ubuntu 10.04,我认为带有调试符号的 libc
版本在 /usr/lib/debug/lib
中。我尝试将我的 LD_LIBRARY_PATH
变量设置为在路径的前面,但这似乎没有任何区别。
我并不完全清楚程序如何选择要加载的共享库,无论是在运行时设置还是在编译时设置(我有点假设运行时,但现在我不确定)。因此,感谢您提供有关如何让 gdb 使用libc
的调试版本的信息。
【问题讨论】:
【参考方案1】:我认为带有调试符号的 libc 版本在 /usr/lib/debug/lib 中。我尝试将我的 LD_LIBRARY_PATH 变量设置为将它放在路径的前面,但这似乎没有任何区别。
这些不是您正在寻找的机器人。
/usr/lib/debug
中的库不是真正的 库。相反,它们包含仅调试信息,但不包含真正的libc.so.6
的.text
或.data
部分。您可以阅读单独的调试信息文件here。
/usr/lib/debug
中的文件来自libc6-dbg
包,只要它们与您安装的libc6
版本匹配,GDB 就会自动加载它们。如果您的libc6
和libc6-dbg
不匹配,您应该会收到来自 GDB 的警告。
您可以通过设置set verbose on
来观察 GDB 试图读取的文件。以下是libc6
和libc6-dbg
匹配时应该看到的内容:
(gdb) set verbose on
(gdb) run
thread_db_load_search returning 0
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.11.1.so...done.
thread_db_load_search returning 0
done.
thread_db_load_search returning 0
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from system-supplied DSO at 0x7ffff7ffb000...done.
WARNING: no debugging symbols found in system-supplied DSO at 0x7ffff7ffb000.
thread_db_load_search returning 0
Reading in symbols for dl-debug.c...done.
Reading in symbols for rtld.c...done.
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.11.1.so...done.
thread_db_load_search returning 0
... etc ...
更新:
例如我看到
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done
这意味着您的 GDB 没有搜索 /usr/lib/debug
。一种可能发生的情况是,如果您在 .gdbinit
中错误地设置了 debug-file-directory
。
这是默认设置:
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".
【讨论】:
感谢您回答我的问题。看起来我还有其他问题,因为当我打开详细输出时,我没有看到 gdb 在/usr/lib/debug
中搜索 libc 的符号。例如我看到Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
所以我还有一些问题,但是你的回答对于理解真正的问题是非常有帮助的。
感谢您的更新。我已经从我的主目录中的源代码下载并安装了 gdb 7.4,因为它有一个错误修复,解决了我在使用 gdb 7.1 时遇到的问题,但我无权更新我系统上的 gdb 版本。无论如何,debug-files-directory
设置不正确,但在.gdbinit
中正确设置似乎可以解决问题。
另外,要进入 gdb 中的 libc 函数,请务必下载 glibc 源代码并解压缩。然后使用源路径运行 gdb directory
命令。如果您正在运行修补 libc 的发行版(例如 Debian),请确保应用相同的补丁(例如通过运行 debuild
),否则源代码行号可能不匹配。【参考方案2】:
确保您已安装 libc 的调试符号:
sudo apt-get install libc6-dbg
如果您在 x64 系统上调试 x86 代码:
sudo apt-get install libc6:i386
sudo apt-get install libc6-dbg:i386
【讨论】:
以上是关于如何使用调试版本的 libc的主要内容,如果未能解决你的问题,请参考以下文章
使用 Xcode/LLDB 打印/调试 libc++ STL
如何摆脱VS 13中的错误“链接:致命错误LNK1104:无法打开文件'LIBC.lib'”?