深入理解debuginfo

最新推荐文章于 2023-11-27 14:01:53 发布
最新推荐文章于 2023-11-27 14:01:53 发布
阅读量2.5w 收藏 53
点赞数 23
分类专栏： Linux 操作系统
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/chinainvent/article/details/24129311
版权

深入理解debuginfo

Google Drive原文

@Chinainvent


一、关于debuginfo的疑惑

程序员应该都知道，为了能够使用gdb跟踪程序，需要在编译期使用gcc的-g选项。而对于系统库或是Linux内核，使用gdb调试或使用systemtap探测时，还需要安装相应的debuginfo包。


例如glibc及它的debuginfo包为：

[yunkai@fedora t]$ rpm -qa | grep glibc

glibc-2.18-12.fc20.x86_64

glibc-debuginfo-2.18-12.fc20.x86_64

...


于是我不禁有如下这些疑问：

  • glibc-debuginfo中包含了什么信息？

  • glibc-debuginfo是如何创建出来的？

  • gdb或systemtap，是如何把glibc与glibc-debuginfo关联起来的？

本文将通过一些例子，来解答这些问题。


二、debuginfo中包含了什么信息？

让我们来看看glibc-debuginfo中，包含有什么内容：

[yunkai@fedora t]$ rpm -ql glibc-debuginfo-2.18-12.fc20.x86_64

/usr/lib/debug

/usr/lib/debug/.build-id

/usr/lib/debug/.build-id/00

/usr/lib/debug/.build-id/00/a32f1b9405f5fcd41a7618f3c2c895ee4aab09

/usr/lib/debug/.build-id/00/a32f1b9405f5fcd41a7618f3c2c895ee4aab09.debug

…

/usr/lib/debug/lib64/libthread_db.so.1.debug

/usr/lib/debug/lib64/libutil-2.18.so.debug

/usr/lib/debug/lib64/libc-2.18.so.debug

…

/usr/src/debug/glibc-2.18/wcsmbs/wcwidth.h

/usr/src/debug/glibc-2.18/wcsmbs/wmemchr.c

/usr/src/debug/glibc-2.18/wcsmbs/wmemcmp.c

...


由上可见，glibc-debuginfo大致有三类文件：

  • 存放在/usr/lib/debug/下的：.build-id/nn/nnn...nnn.debug文件，文件名是hash key。

  • 存放在/usr/lib/debug/下的其它*.debug文件，其文件名，是库文件名+.debug后缀。

  • glibc的源代码


当使用gdb调试时，需要在机器码与源代码之间，建立起映射关系。这就需要三个信息：

  • 机器码：可执行文件、动态链接库，例如：/lib64/libc-2.18.so

  • 源代码：显然就是glibc-debuginfo中，包含的*.c和*.h等源文件。

  • 映射关系：你应该猜到了，它们就保存在*.debug文件中。


三、debuginfo是如何创建出来的？

当我们使用gcc的-g选项编译程序时，机器码与源代码的映射关系，会被默认地与可执行程序、动态链接库合并在一起。例如下面a.out可执行程序，已经包含了映射关系：

[yunkai@fedora t]$ nl main.c

    1  #include <stdio.h>

      

    2  int main()

    3  {

    4    printf("hello, world!\n");

    5    return 0;

    6  }

[yunkai@fedora t]$ gcc -g main.c

[yunkai@fedora t]$ ls -l

total 16

-rwxrwxr-x 1 yunkai yunkai 9502 Apr  9 14:55 a.out

-rw-rw-r-- 1 yunkai yunkai   76 Apr  9 14:49 main.c


把映射关系等调试信息，与可执行文件、动态链接库合并在一起，会带来一个显著的问题：可执行文件或库的Size变得很大。这对于那些不关心调试信息的普通用户，是不必要的。


例如，Linux的内核，如果带上Debuginfo，会无谓的增加几百M的大小。如果一个Linux操作系统的所有库都带上各自的Debuginfo，那么光是一个干净的操作系统，就需要浪费掉几G甚至十几G的磁盘空间。如果是通过网络安装，还将浪费所有用户的带宽，并显著的拖慢安装的进度。正是了为解决这个问题，在Linux上的各种程序和库，在生成RPM时，就已经把Debuginfo单独的抽取出来，因此形成了独立的debuginfo包。


问题是，如何让程序生成分离的debuginfo呢？我们可以通过objcopy命令的--only-keep-debug选项来实现，下面的命令把调试信息从a.out中读取出来，写到a.out.debug文件中：

[yunkai@fedora t]$ objcopy --only-keep-debug ./a.out a.out.debug

[yunkai@fedora t]$ ls -l

total 24

-rwxrwxr-x 1 yunkai yunkai 9502 Apr  9 14:55 a.out

-rwxrwxr-x 1 yunkai yunkai 6022 Apr  9 15:22 a.out.debug

-rw-rw-r-- 1 yunkai yunkai   76 Apr  9 14:49 main.c

既然已经把调试信息，保存到了a.out.debug文件中，就可以通过objcopy的--strip-debug选项给a.out瘦身了（也可以使用strip --strip-debug ./a.out，效果一样）：

[yunkai@fedora t]$ objcopy --strip-debug ./a.out

[yunkai@fedora t]$ ls -l

total 24

-rwxrwxr-x 1 yunkai yunkai 8388 Apr  9 15:27 a.out

-rwxrwxr-x 1 yunkai yunkai 6022 Apr  9 15:22 a.out.debug

-rw-rw-r-- 1 yunkai yunkai   76 Apr  9 14:49 main.c


当把调试信息从a.out中清除后，使用gdb对a.out进行调试，会报no debugging symbols found：

[yunkai@fedora t]$ gdb ./a.out

GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20

...

Reading symbols from /home/yunkai/t/a.out...(no debugging symbols found)...done.

(gdb)


显然，gdb找不到调试信息了。因此，我们需要在a.out中埋下一些线索，以便gdb借助这些线索，可以正确地查找到它对应的debug文件：a.out.debug。


在Linux下，可执行文件或库，通常是ELF(Executable and Linkable Format)格式。这种格式，含有session headers。而调试信息的线索，正好可以通过一个约定的session header来保存，它叫.gnu_debuglink。可通过objcopy的--add-gnu-debuglink选项，把调试信息的文件名（a.out.debug）保存到a.out的.gnu_debuglink这个header中。然后gdb就可以正常调试了：

[yunkai@fedora t]$ objcopy --add-gnu-debuglink=a.out.debug ./a.out

[yunkai@fedora t]$ objdump -s -j .gnu_debuglink ./a.out


./a.out:     file format elf64-x86-64


Contents of section .gnu_debuglink:

0000 612e6f75 742e6465 62756700 3fe5803b  a.out.debug.?..;

[yunkai@fedora t]$ gdb a.out

...

Reading symbols from /home/yunkai/t/a.out...Reading symbols from /home/yunkai/t/a.out.debug...done.


上面的objcopy命令，其实是把a.out.debug的文件名以及这个文件的CRC校验码，写到了.gnu_debuglink这个header的值中，但是并没有告诉a.out.debug所在的路径（上面通过objdump命令，可以打印出.gnu_debuglink这个header的内容）。


那么gdb是按照怎样的规则，去查找a.out.debug文件呢？在解答这个问题之前，我们先来看另一个session header，叫.note.gnu.build-id：

[yunkai@fedora t]$ readelf -t ./a.out | grep build-id

 [ 3] .note.gnu.build-id

[yunkai@fedora t]$ readelf -n ./a.out

...

Notes at offset 0x00000274 with length 0x00000024:

 Owner                 Data size       Description

 GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)

   Build ID: 888010ffb999590e7158422ea813169be34085a1


[yunkai@fedora t]$ readelf -n ./a.out.debug

...

Notes at offset 0x00000274 with length 0x00000024:

 Owner                 Data size       Description

 GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)

   Build ID: 888010ffb999590e7158422ea813169be34085a1


这个session header是a.out原生就存在的，因此也被拷贝到了a.out.debug中。这个header，保存了一个Build ID，这个ID是根据a.out文件自动计算出来的，每个执行文件或库，都有它唯一的Build ID。


在第2节中，我们注意到这种文件：.build-id/nn/nnnn...nnnn.debug，前两个“nn”就是它的Build ID前两位，后面的nnnn...nnnn则是Build ID的剩余部分。而这个nnnn...nnnn.debug文件，只是改了个名字而已。


而gdb，则是通过下面的顺序查找a.out.debug文件：

  1. <global debug directory>/.build-id/nn/nnnn...nnnn.a.out.debug

  2. <the path of a.out>/a.out.debug

  3. <the path of a.out>/.debug/a.out.debug

  4. <global debug directory>/<the patch of a.out>/a.out.debug


而<global debug directory>默认为/usr/lib/debug/。可以在gdb中，通过set/show debug-file-directory命令来设置或查看这个值：

[yunkai@fedora t]$ gdb ./a.out

...

(gdb) show debug-file-directory

The directory where separate debug symbols are searched for is "/usr/lib/debug".



既然a.out的Build ID为：888010ffb999590e7158422ea813169be34085a1，可以把a.out.debug文件，移动到/usr/lib/debug/.build-id/88/8010ffb999590e7158422ea813169be34085a1.debug：

[yunkai@fedora t]$ sudo cp a.out.debug \

/usr/lib/debug/.build-id/88/8010ffb999590e7158422ea813169be34085a1.debug

[yunkai@fedora t]$ gdb ./a.out

...

Reading symbols from /home/yunkai/t/a.out...Reading symbols from /usr/lib/debug/.build-id/88/8010ffb999590e7158422ea813169be34085a1.debug...done.

done.


由上可见，gdb就会优先从/usr/lib/debug/.build-id/查找到对应的debug信息。


四、a.out.debug里有什么内容？

gcc目前会默认会采用DWARF 4格式来保存调试信息。可以通过readelf -w来查看DWARF的内容：

[yunkai@fedora t]$ readelf -w ./a.out.debug

...

Contents of the .debug_info section:


 Compilation Unit @ offset 0x0:

  Length:        0x8d (32-bit)

  Version:       4

  Abbrev Offset: 0x0

  Pointer Size:  8

<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)

   <c>   DW_AT_producer    : (indirect string, offset: 0x6a): GNU C 4.8.2 20131212 (Red Hat 4.8.2-7) -mtune=generic -march=x86-64 -g

   <10>   DW_AT_language    : 1        (ANSI C)

   <11>   DW_AT_name        : (indirect string, offset: 0x2f): main.c

   <15>   DW_AT_comp_dir    : (indirect string, offset: 0x5b): /home/yunkai/t

...


DWARF内部通过DIE(Debugging Information Entry)，形成一颗调用树，DWARF在设计的时候，就考虑到了各种语言的支持，虽然它通常与ELF格式的文件一起工作，但它其实并不依赖ELF。


由于DWARF比较自由的设计，使它不仅支持C/C++，也支持Java/Python等等几乎所有语言的调试信息的表达。


在DWARF里，通常包含：源代码与机器码的映射关系的行号表、宏信息、inline函数的信息、Call Frame信息等。


但对于普通用户，通常不需要了解DWARF的太多细节，如果好奇的话，推荐阅读文献5。


五、在代码中生成Marker探针

通过gcc的-g选项，所有函数名，都会自动的生成相应的debuginfo，供systemtap进行探测，这种方法在英文上称为：Debuginfo-based instrumentation，它的局限性在于，只能收集到函数调用的初始时刻、以及函数返回的结束时刻的上下文信息。


为了解决这个问题，又提出了一种新方法：Compiled-in instrumentation，它可以让程序员，把探针安插到指定的某行代码中，从而可以收集到那行代码执行时的上下文信息，这种探针被称为Marker探针。


编写Marker探针，需要在代码中包含头文件：

#include <sys/sdt.h>


然后在目标行，插入下面的Marker宏之一：

DTRACE_PROBE(provider, name)

DTRACE_PROBE4(provider, name, arg1, arg2, arg3, arg4)


写好Marker探针并成功编译后，可以使用下面的systemtap指令来查看Marker探针是否生效：

stap -L 'process("/path/to/a.out").mark("*")'


更具体的操作方法详见文献6，值得一提的是，Marker探针是非常轻量的，它几乎对程序的性能没有影响，因为它只会在代码中生成nop汇编指令。它是通过把现场的上下文信息，保存在ELF文件的特定的section header(.stapsdt.base)来实现的，只会增加debuginfo文件的大小。

六、参考文献

  1. http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

  2. http://sourceware.org/binutils/docs-2.17/binutils/objcopy.html

  3. https://blogs.oracle.com/dbx/entry/gnu_debuglink_or_debugging_system

  4. https://blogs.oracle.com/dbx/entry/creating_separate_debug_info

  5. http://dwarfstd.org/doc/DWARF4.pdf

  6. https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps

Chinainvent
关注
  • 23
    点赞
  • 踩
  • 53
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
kernel-debuginfo
05-06
Centos 7.3系统在系统异常崩溃后需要安装debuginfo进行调试。
linux安装debuginfo
qq_39009661的博客
02-28 4535
1、可以 yum install --enablerepo=base-debuginfo kernel-debuginfo-3.10.0-957.1.3.el7.x86_64 2、去http://debuginfo.centos.org/ 下面的 6 / 7的x86_64去找相应版本的包
DebugInfo 模块功能系统介绍 文本上色 文本与表格对齐 分隔线 秒表计算器 语义日期
dyy123
08-27 186
python DebugInfo 彩色文本 文本颜色 文本对齐 中文对齐 居中对齐 中文左对齐 中文右对齐 数字对齐 打印分隔线 秒表装饰器 语义日期
linux debuginfo 文件操作
ld11690的专栏
10-18 1527
转自 http://blog.csdn.net/force_eagle/article/details/51980558 linux 下分离 debuginfo 到独立文件. [plain] view plain copy gcc -ggdb utmp.c -o utmp   readelf -S utmp   # 创建一个包含 d
debuginfo介绍
weixin_33937913的博客
06-15 1082
一、简介   深入理解debuginfo http://blog.csdn.net/chinainvent/article/details/24129311?reload   关于DWARF http://www.cnblogs.com/catch/p/3884271.html     二、gdb调试问题 Missing separate debuginfos, use: debu...
rpm debuginfo包的作用
chenj_freedom的技术点滴
11-13 6375
首先看一个例子 case1 main.c #include &lt;stdio.h&gt; int main() { int a=1; int b=2; int c=0; c=a+b; printf("c=%d\n",c); return 0; } gcc main.c -o main 生成可执行文件./main 然后gdb一下，如下： 因为，gcc默认是-O2选项，不含调试...
日志级别的选择：Debug、Info、Warn、Error还是Fatal
weixin_30518397的博客
06-13 3324
日志信息分类 1.等级由低到高：debug<info<warn<Error<Fatal; 2.区别： debug 级别最低，可以随意的使用于任何觉得有利于在调试时更详细的了解系统运行状态的东东； info 重要，输出信息：用来反馈系统的当前状态给最终用户的； 后三个，警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态。 warn, 可修复，...
[调试技术] GDB概述和常用用法
ykun089的博客
05-26 526
前言： linux环境下几乎只有gdb可用，windows环境下windbg也是以gdb作为底部承载，因此gdb的重要作用可见一斑，但gdb作为基础套件，其不具备界面展示，因此使用起来不是很方便，这里对其做简要的使用说明。 前提条件： 使用gdb进行调试必须满足以下至少一个条件： 1）在编译时使用了-g选项，那么得到的二进制文件便是包含调试信息的，那么此二进制文件是可调试的； 2） 编译时没使用-g选项增加调试信息，但有与此二进制文件配套的debuginfo包，那么可以将此debuginfo.
log4j里面的info，debug，error级别有什么区别
zhangfx5的博客
10-28 8679
一共分为五个级别：DEBUG、INFO、WARN、ERROR和FATAL。这五个级别是有顺序的，DEBUG < INFO < WARN < ERROR < FATAL，明白这一点很重要，这里Log4j有一个规则：假设设置了级别为P，如果发生了一个级别Q比P高，则可以启动，否则屏蔽掉。 DEBUG: 这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出.
gdb调试单独的debuginfo文件
最新发布
EmptyStupid的博客
11-27 1079
本文主要介绍了如何制作单独的debuginfo文件，如何使用gdb调试单独的debuginfo文件。
CentOS-Debuginfo.repo
06-01
CentOS-Debuginfo.repo
rhel-debuginfo.repo
01-07
#CentOS-Base.repo # # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client...
matrixdb-debuginfo
09-06
matrixdb-debuginfo
nss-softokn-debuginfo-3.12.9-11.el6.i686.rpm gcc-libraries-debug
10-12
nss-softokn-debuginfo-3.12.9-11.el6.i686.rpm gcc-libraries-debug
glibc-debuginfo-2.12
10-11
glibc-debuginfo-2.12 不同小版本的rpm安装包，主要用于redhat下glibc debuginfo相关rpm包的安装
pgpool-II-pg11-debuginfo-4.0.9-1pgdg.rhel7.x86_64.rpm
06-29
pgpool-II-pg11-debuginfo-4.0.9-1pgdg.rhel6.x86_64.rpm
tp_debug_info.txt
05-29
tp_debug_info.txt
glibc gcc debuginfo rpm from redhat
10-13
glibc gcc debuginfo rpm from redhat
SUSE源码包与debuginfo包-附件资源
03-02
SUSE源码包与debuginfo包-附件资源
glibc-debuginfo rpm安装
10-23
glibc-debuginfo rpm是一个用于调试glibc库的软件包。它包含了用于分析和调试glibc库的符号文件和调试信息。 要安装glibc-debuginfo rpm，首先需要确保已经安装了glibc库。在安装glibc的基础上，可以通过以下步骤来安装glibc-debuginfo rpm： 1. 首先，使用root权限登录系统。 2. 打开终端窗口，并使用以下命令安装glibc-debuginfo rpm： ``` yum install glibc-debuginfo ``` 这将使用yum包管理器从已配置的软件源中下载并安装glibc-debuginfo rpm包及其依赖项。 3. 安装完成后，您可以使用以下命令来验证安装是否成功： ``` rpm -q glibc-debuginfo ``` 如果成功安装，则会显示glibc-debuginfo rpm的版本信息。 安装glibc-debuginfo rpm后，您将能够在调试glibc相关的问题时，使用工具如gdb来分析和调试glibc库。这些符号文件和调试信息可以提供有关函数调用、变量值、堆栈跟踪等关键信息，以帮助定位和解决与glibc库相关的问题。 请注意，安装glibc-debuginfo rpm可能会占用较多的磁盘空间，因为它包含大量的符号文件和调试信息。在安装之前，请确保您的系统有足够的磁盘空间可供使用，并在不需要时及时清理不必要的调试信息和符号文件。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值