如何使用libc的调试版本 [英] How to use debug version of libc

查看:480
本文介绍了如何使用libc的调试版本的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述


如何让gdb使用libc的调试符号?



更长的版本:
我正在使用gdb调试程序,我想查看libc使用的futex的信息。然而,在调试过程中的某个时刻,我得到的输出如下:

  Catchpoint 2(调用syscall futex),0x00007ffff772b73e ()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从/lib/libc.so.6获得vfprintf()中的
#3 0x00007ffff768565a来自/lib/libc.so中的printf()。 6
....

当我运行 info sharedlibrary in gdb at the breakpoint我看到:

 (gdb)info sharedlibrary 
From To Syms读共享对象库
0x00007ffff7dddaf0 0x00007ffff7df6704是(*)/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc53e0 0x00007ffff7bd1388是(*)/lib/libpthread.so.0
0x00007ffff79ba190 0x00007ffff79bd7d8是(*)/lib/librt.so.1
0x00007ffff76538c0 0x00007ffff7766c60是(*)/lib/libc.so.6
0x00007ffff6c1fd80 0x00007ffff6c303c8是(*)/lib/libgcc_s.so.1
(*):共享库缺少调试信息。

当我运行 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的调试版本的信息是值得赞赏的。

解决方案


I认为具有调试符号的libc版本位于/ usr / lib / debug / lib中。我尝试设置我的LD_LIBRARY_PATH变量,使其位于路径的前端,但似乎没有什么区别。


这些是 您正在寻找的机器人。


$ b / usr / lib / debug中的库不是 real 库。而是包含 only 调试信息,但不包含 .text .data 部分真正的 libc.so.6 。您可以阅读此处的单独debuginfo文件。


$ b $ < / usr / lib / debug 中的文件来自 libc6-dbg 包,并且GDB会自动加载它们,只要它们与您安装的 libc6 版本匹配。如果您的 libc6 libc6-dbg 不匹配,您应该从GDB收到警告。



您可以通过在上设置 set verbose来观察GDB试图读取的文件。以下是您在 libc6 libc6-dbg 匹配时应该看到的内容:

 (gdb)set 
(gdb)run
thread_db_load_search返回0
读取/ lib64 / ld-linux- x86-64.so.2 ...读取/usr/lib/debug/lib/ld-2.11.1.so...done中的符号。
thread_db_load_search返回0
完成。
thread_db_load_search返回0
为/lib64/ld-linux-x86-64.so.2加载的符号
从系统提供的DSO读取符号0x7ffff7ffb000 ... done。
警告:在系统提供的DSO中找不到在0x7ffff7ffb000处的调试符号。
thread_db_load_search返回0
读取符号中的dl-debug.c ... done。
在符号中读取rtld.c ...完成。
读取/lib/librt.so.1...中的符号从/usr/lib/debug/lib/librt-2.11.1.so...done中读取符号。
thread_db_load_search返回0
... etc ...

更新:


例如,我看到

读取/lib/libc.so.6中的符号。 ..(没有找到调试符号)... done


这意味着你的GDB不搜索 / usr / lib中/调试。一种可能发生的方式是,如果在 .gdbinit 中错误地设置了 debug-file-directory



这是默认设置:

 (gdb)show debug-file-directory 
单独调试符号搜索的目录是/ usr / lib / debug。


Short version of question: How can I get gdb to use the debugging symbols for libc?

Longer version: I am debugging a program with gdb and I want to see information about a futex used by libc. However, at some point during debugging I get output such as:

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
....

When I run info sharedlibrary in gdb at the breakpoint I see:

(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.

And when I run ldd I see:

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)

I am using Ubuntu 10.04 and I think that the version of libc with debug symbols is in /usr/lib/debug/lib. I tried setting my LD_LIBRARY_PATH variable to have this at the front of the path but that did not seem to make a difference.

I'm not completely clear on how the program chooses which shared libraries to load, whether this is set at runtime or compile time (I sort of assumed runtime but now I'm not sure). So information on how to get gdb to use the debug version of libc is appreciated.

解决方案

I think that the version of libc with debug symbols is in /usr/lib/debug/lib. I tried setting my LD_LIBRARY_PATH variable to have this at the front of the path but that did not seem to make a difference.

These are not the droids you are looking for.

The libraries in /usr/lib/debug are not real libraries. Rather, the contain only debug info, but do not contain .text nor .data sections of the real libc.so.6. You can read about the separate debuginfo files here.

The files in /usr/lib/debug come from libc6-dbg package, and GDB will load them automatically, so long as they match your installed libc6 version. If your libc6 and libc6-dbg do not match, you should get a warning from GDB.

You can observe the files GDB is attempting to read by setting set verbose on. Here is what you should see when libc6 and libc6-dbg do match:

(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 ...

Update:

For instance I see
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done

That implies that your GDB is not searching /usr/lib/debug. One way that could happen is if you set debug-file-directory in your .gdbinit incorrectly.

Here is the default setting:

(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".

这篇关于如何使用libc的调试版本的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆