kk Blog —— 通用基础


date [-d @int|str] [+%s|"+%F %T"]
netstat -ltunp
sar -n DEV 1

GDB MI接口相关

所谓GDB MI就是GNU Debugger Machine-Interface,是GNU设计来给其它前端使用的交互协议.

说实在的,这个接口设计得并不是很好,仅仅是能用而已.它的指令和GDB/CLI即GDB Command Line Interface基本是对应的.
为 了方便机器交互,它把允许所有的指令有一个前缀,比如901-stack-list-frames 0 99.这样,在GDB返回的结果前,也会有同样的前缀901,我们可以根据这个前缀进行命令/结果匹配. 同时它还保证结果格式的统一性.不会出现CLI那种百花齐放的结果.当然,如果你安了GDB的python插件来做变量格式化,就可能出现例外的情况.

它的命令有同步的,也有异步的.这对于前端的设计是个很大的障碍,而且除了命令结果以外,它还会有很多异步的消息,事件…这些东西混在一起,处理起来会相当麻烦.

这是 GDB/MI的官方文档 有兴趣的话可以仔细研究一下.

调试器工作原理之三——调试信息

调试器工作原理之一——基础篇
调试器工作原理之二——实现断点
调试器工作原理之三——调试信息

本篇主要内容

在本文中我将向大家解释关于调试器是如何在机器码中寻找C函数以及变量的，以及调试器使用了何种数据能够在C源代码的行号和机器码中来回映射。

调试信息

现代的编译器在转换高级语言程序代码上做得十分出色，能够将源代码中漂亮的缩进、嵌套的控制结构以及任意类型的 变量全都转化为一长串的比特流——这就是机器码。这么做的唯一目的就是希望程序能在目标CPU上尽可能快的运行。大多数的C代码都被转化为一些机器码指 令。变量散落在各处——在栈空间里、在寄存器里，甚至完全被编译器优化掉。结构体和对象甚至在生成的目标代码中根本不存在——它们只不过是对内存缓冲区中 偏移量的抽象化表示。

那么当你在某些函数的入口处设置断点时，调试器如何知道该在哪里停止目标进程的运行呢？当你希望查看一个变量的值时，调试器又是如何找到它并展示给你呢？答案就是——调试信息。

调试信息是在编译器生成机器码的时候一起产生的。它代表着可执行程序和源代码之间的关系。这个信息以预定义的格式进行编码，并同机器码一起存储。许 多年以来，针对不同的平台和可执行文件，人们发明了许多这样的编码格式。由于本文的主要目的不是介绍这些格式的历史渊源，而是为您展示它们的工作原理，所 以我们只介绍一种最重要的格式，这就是DWARF。作为Linux以及其他类Unix平台上的ELF可执行文件的调试信息格式，如今的DWARF可以说是 无处不在。

ELF文件中的DWARF格式

根据维基百科上的词条解释，DWARF是同ELF可执行文件格式一同设计出来的，尽管在理论上DWARF也能够嵌入到其它的对象文件格式中。

DWARF是一种复杂的格式，在多种体系结构和操作系统上经过多年的探索之后，人们才在之前的格式基础上创建了DWARF。它肯定是很复杂的，因为 它解决了一个非常棘手的问题——为任意类型的高级语言和调试器之间提供调试信息，支持任意一种平台和应用程序二进制接口（ABI）。要完全解释清楚这个主 题，本文就显得太微不足道了。说实话，我也不理解其中的所有角落。本文我将采取更加实践的方法，只介绍足量的DWARF相关知识，能够阐明实际工作中调试 信息是如何发挥其作用的就可以了。

ELF文件中的调试段

首先，让我们看看DWARF格式信息处在ELF文件中的什么位置上。ELF可以为每个目标文件定义任意多个段（section）。而Section header表中则定义了实际存在有哪些段，以及它们的名称。不同的工具以各自特殊的方式来处理这些不同的段，比如链接器只寻找它关注的段信息，而调试器 则只关注其他的段。 我们通过下面的C代码构建一个名为traceprog2的可执行文件来做下实验。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#include <stdio.h>
 
void do_stuff(int my_arg)
{
	int my_local = my_arg + 2;
	int i;
 
	for (i = 0; i < my_local; ++i)
		printf("i = %d\n", i);
}
 
int main()
{
	do_stuff(2);
	return 0;
}

通过objdump –h导出ELF可执行文件中的段头信息，我们注意到其中有几个段的名字是以.debug_打头的，这些就是DWARF格式的调试段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

26 .debug_aranges 00000020  00000000  00000000  00001037
                  CONTENTS, READONLY, DEBUGGING
27 .debug_pubnames    00000028  00000000  00000000  00001057
                  CONTENTS, READONLY, DEBUGGING
28 .debug_info    000000cc  00000000  00000000  0000107f
                  CONTENTS, READONLY, DEBUGGING
29 .debug_abbrev  0000008a  00000000  00000000  0000114b
                  CONTENTS, READONLY, DEBUGGING
30 .debug_line    0000006b  00000000  00000000  000011d5
                  CONTENTS, READONLY, DEBUGGING
31 .debug_frame   00000044  00000000  00000000  00001240
                  CONTENTS, READONLY, DEBUGGING
32 .debug_str     000000ae  00000000  00000000  00001284
                  CONTENTS, READONLY, DEBUGGING
33 .debug_loc     00000058  00000000  00000000  00001332
                  CONTENTS, READONLY, DEBUGGING

每行的第一个数字表示每个段的大小，而最后一个数字表示距离ELF文件开始处的偏移量。调试器就是利用这个信息来从可执行文件中读取相关的段信息。现在，让我们通过一些实际的例子来看看如何在DWARF中找寻有用的调试信息。

定位函数

当我们在调试程序时，一个最为基本的操作就是在某些函数中设置断点，期望调试器能在函数入口处将程序断下。要完成这个功能，调试器必须具有某种能够从源代码中的函数名称到机器码中该函数的起始指令间相映射的能力。

这个信息可以通过从DWARF中的.debug_info段获取到。在我们继续之前，先说点背景知识。DWARF的基本描述实体被称为调试信息表项 （Debugging Information Entry —— DIE），每个DIE有一个标签——包含它的类型，以及一组属性。各个DIE之间通过兄弟和孩子结点互相链接，属性值可以指向其他的DIE。
我们运行

1

objdump –dwarf=info traceprog2

得到的输出非常长，对于这个例子，我们只用关注这几行就可以了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<1><71>: Abbrev Number: 5 (DW_TAG_subprogram)
  <72>   DW_AT_external : 1
  <73>   DW_AT_name     : (...): do_stuff
  <77>   DW_AT_decl_file    : 1
  <78>   DW_AT_decl_line    : 4
  <79>   DW_AT_prototyped   : 1
  <7a>   DW_AT_low_pc       : 0x8048604
  <7e>   DW_AT_high_pc  : 0x804863e
  <82>   DW_AT_frame_base   : 0x0     (location list)
  <86>   DW_AT_sibling  : <0xb3>
 
<1><b3>: Abbrev Number: 9 (DW_TAG_subprogram)
  <b4>   DW_AT_external : 1
  <b5>   DW_AT_name     : (...): main
  <b9>   DW_AT_decl_file  : 1
  <ba>   DW_AT_decl_line  : 14
  <bb>   DW_AT_type     : <0x4b>
  <bf>   DW_AT_low_pc       : 0x804863e
  <c3>   DW_AT_high_pc  : 0x804865a
<c7>   DW_AT_frame_base     : 0x2c   (location list)

这里有两个被标记为DW_TAG_subprogram的DIE，从DWARF的角度看这就是函数。注意，这里do_stuff和main都各有一 个表项。这里有许多有趣的属性，但我们感兴趣的是DW_AT_low_pc。这就是函数起始处的程序计数器的值（x86下的EIP）。注意，对于 do_stuff来说，这个值是0×8048604。现在让我们看看，通过objdump –d做反汇编后这个地址是什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

08048604 <do_stuff>:
 8048604:       55           push   ebp
 8048605:       89 e5        mov    ebp,esp
 8048607:       83 ec 28     sub    esp,0x28
 804860a:       8b 45 08     mov    eax,DWORD PTR [ebp+0x8]
 804860d:       83 c0 02     add    eax,0x2
 8048610:       89 45 f4     mov    DWORD PTR [ebp-0xc],eax
 8048613:       c7 45 (...)  mov    DWORD PTR [ebp-0x10],0x0
 804861a:       eb 18        jmp    8048634 <do_stuff+0x30>
 804861c:       b8 20 (...)  mov    eax,0x8048720
 8048621:       8b 55 f0     mov    edx,DWORD PTR [ebp-0x10]
 8048624:       89 54 24 04  mov    DWORD PTR [esp+0x4],edx
 8048628:       89 04 24     mov    DWORD PTR [esp],eax
 804862b:       e8 04 (...)  call   8048534 <printf@plt>
 8048630:       83 45 f0 01  add    DWORD PTR [ebp-0x10],0x1
 8048634:       8b 45 f0     mov    eax,DWORD PTR [ebp-0x10]
 8048637:       3b 45 f4     cmp    eax,DWORD PTR [ebp-0xc]
 804863a:       7c e0        jl     804861c <do_stuff+0x18>
 804863c:       c9           leave
 804863d:       c3           ret

没错，从反汇编结果来看0×8048604确实就是函数do_stuff的起始地址。因此，这里调试器就同函数和它们在可执行文件中的位置确立了映射关系。

定位变量

假设我们确实在do_stuff中的断点处停了下来。我们希望调试器能够告诉我们my_local变量的值，调试器怎么知道去哪里找到相关的信息 呢？这可比定位函数要难多了，因为变量可以在全局数据区，可以在栈上，甚至是在寄存器中。另外，具有相同名称的变量在不同的词法作用域中可能有不同的值。 调试信息必须能够反映出所有这些变化，而DWARF确实能做到这些。

我不会涵盖所有的可能情况，作为例子，我将只展示调试器如何在do_stuff函数中定位到变量my_local。我们从.debug_info段开始，再次看看do_stuff这一项，这一次我们也看看其他的子项：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<1><71>: Abbrev Number: 5 (DW_TAG_subprogram)
    <72>   DW_AT_external    : 1
    <73>   DW_AT_name        : (...): do_stuff
    <77>   DW_AT_decl_file   : 1
    <78>   DW_AT_decl_line   : 4
    <79>   DW_AT_prototyped  : 1
    <7a>   DW_AT_low_pc      : 0x8048604
    <7e>   DW_AT_high_pc     : 0x804863e
    <82>   DW_AT_frame_base  : 0x0      (location list)
    <86>   DW_AT_sibling     : <0xb3>
 <2><8a>: Abbrev Number: 6 (DW_TAG_formal_parameter)
    <8b>   DW_AT_name        : (...): my_arg
    <8f>   DW_AT_decl_file   : 1
    <90>   DW_AT_decl_line   : 4
    <91>   DW_AT_type        : <0x4b>
    <95>   DW_AT_location    : (...)       (DW_OP_fbreg: 0)
 <2><98>: Abbrev Number: 7 (DW_TAG_variable)
    <99>   DW_AT_name        : (...): my_local
    <9d>   DW_AT_decl_file   : 1
    <9e>   DW_AT_decl_line   : 6
    <9f>   DW_AT_type        : <0x4b>
    <a3>   DW_AT_location    : (...)      (DW_OP_fbreg: -20)
<2><a6>: Abbrev Number: 8 (DW_TAG_variable)
    <a7>   DW_AT_name        : i
    <a9>   DW_AT_decl_file   : 1
    <aa>   DW_AT_decl_line   : 7
    <ab>   DW_AT_type        : <0x4b>
<af>   DW_AT_location    : (...)      (DW_OP_fbreg: -24)

注意每一个表项中第一个尖括号里的数字，这表示嵌套层次——在这个例子中带有<2>的表项都是表项<1>的子项。因此我们 知道变量my_local（以DW_TAG_variable作为标签）是函数do_stuff的一个子项。调试器同样还对变量的类型感兴趣，这样才能正 确的显示变量的值。这里my_local的类型根据DW_AT_type标签可知为<0x4b>。如果查看objdump的输出，我们会发现 这是一个有符号4字节整数。

要在执行进程的内存映像中实际定位到变量，调试器需要检查DW_AT_location属性。对于my_local来说，这个属性为 DW_OP_fberg: -20。这表示变量存储在从所包含它的函数的DW_AT_frame_base属性开始偏移-20处，而DW_AT_frame_base正代表了该函数 的栈帧起始点。

函数do_stuff的DW_AT_frame_base属性的值是0×0（location list），这表示该值必须要在location list段去查询。我们看看objdump的输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ objdump --dwarf=loc tracedprog2
 
tracedprog2:     file format elf32-i386
 
Contents of the .debug_loc section:
 
    Offset   Begin    End      Expression
    00000000 08048604 08048605 (DW_OP_breg4: 4 )
    00000000 08048605 08048607 (DW_OP_breg4: 8 )
    00000000 08048607 0804863e (DW_OP_breg5: 8 )
    00000000 <End of list>
    0000002c 0804863e 0804863f (DW_OP_breg4: 4 )
    0000002c 0804863f 08048641 (DW_OP_breg4: 8 )
    0000002c 08048641 0804865a (DW_OP_breg5: 8 )
0000002c <End of list>

关于位置信息，我们这里感兴趣的就是第一个。对于调试器可能定位到的每一个地址，它都会指定当前栈帧到变量间的偏移量，而这个偏移就是通过寄存器来计算的。对于x86体系结构，bpreg4代表esp寄存器，而bpreg5代表ebp寄存器。

让我们再看看do_stuff的开头几条指令：

1
2
3
4
5
6
7

08048604 <do_stuff>:
 8048604:       55          push   ebp
 8048605:       89 e5       mov    ebp,esp
 8048607:       83 ec 28    sub    esp,0x28
 804860a:       8b 45 08    mov    eax,DWORD PTR [ebp+0x8]
 804860d:       83 c0 02    add    eax,0x2
 8048610:       89 45 f4    mov    DWORD PTR [ebp-0xc],eax

注意，ebp只有在第二条指令执行后才与我们建立起关联，对于前两个地址，基地址由前面列出的位置信息中的esp计算得出。一旦得到了ebp的有效值，就可以很方便的计算出与它之间的偏移量。因为之后ebp保持不变，而esp会随着数据压栈和出栈不断移动。

那么这到底为我们定位变量my_local留下了什么线索？我们感兴趣的只是在地址0×8048610上的指令执行过后my_local的值（这里 my_local的值会通过eax寄存器计算，而后放入内存）。因此调试器需要用到DW_OP_breg5: 8 基址来定位。现在回顾一下my_local的DW_AT_location属性：DW_OP_fbreg: -20。做下算数：从基址开始偏移-20，那就是ebp – 20，再偏移+8，我们得到ebp – 12。现在再看看反汇编输出，注意到数据确实是从eax寄存器中得到的，而ebp – 12就是my_local存储的位置。

定位到行号

当我说到在调试信息中寻找函数时，我撒了个小小的谎。当我们调试C源代码并在函数中放置了一个断点时，我们通常并不会对第一条机器码指令感兴趣。我们真正感兴趣的是函数中的第一行C代码。

这就是为什么DWARF在可执行文件中对C源码到机器码地址做了全部映射。这部分信息包含在.debug_line段中，可以按照可读的形式进行解读：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ objdump --dwarf=decodedline tracedprog2
 
tracedprog2:     file format elf32-i386
 
Decoded dump of debug contents of section .debug_line:
 
CU: /home/eliben/eli/eliben-code/debugger/tracedprog2.c:
File name           Line number    Starting address
tracedprog2.c                5           0x8048604
tracedprog2.c                6           0x804860a
tracedprog2.c                9           0x8048613
tracedprog2.c               10           0x804861c
tracedprog2.c                9           0x8048630
tracedprog2.c               11           0x804863c
tracedprog2.c               15           0x804863e
tracedprog2.c               16           0x8048647
tracedprog2.c               17           0x8048653
tracedprog2.c               18           0x8048658

不难看出C源码同反汇编输出之间的关系。第5行源码指向函数do_stuff的入口点——地址0×8040604。接下第6行源码，当在 do_stuff上设置断点时，这里就是调试器实际应该停下的地方，它指向地址0x804860a——刚过do_stuff的开场白。这个行信息能够方便 的在C源码的行号同指令地址间建立双向的映射关系。
1. 当在某一行上设定断点时，调试器将利用行信息找到实际应该陷入的地址（还记得前一篇中的int 3指令吗？）
2. 当某个指令引起段错误时，调试器会利用行信息反过来找出源代码中的行号，并告诉用户。

libdwarf —— 在程序中访问DWARF

通过命令行工具来访问DWARF信息这虽然有用但还不能完全令我们满意。作为程序员，我们希望知道应该如何写出实际的代码来解析DWARF格式并从中读取我们需要的信息。

自然的，一种方法就是拿起DWARF规范开始钻研。还记得每个人都告诉你永远不要自己手动解析HTML，而应该使用函数库来做吗？没错，如果你要手 动解析DWARF的话情况会更糟糕，DWARF比HTML要复杂的多。本文展示的只是冰山一角而已。更困难的是，在实际的目标文件中，这些信息大部分都以 非常紧凑和压缩的方式进行编码处理。

因此我们要走另一条路，使用一个函数库来同DWARF打交道。我知道的这类函数库主要有两个：
1. BFD（libbfd），GNU binutils就是使用的它，包括本文中多次使用到的工具objdump，ld（GNU链接器），以及as（GNU汇编器）。
2. libdwarf —— 同它的老大哥libelf一样，为Solaris以及FreeBSD系统上的工具服务。
我这里选择了libdwarf，因为对我来说它看起来没那么神秘，而且license更加自由（LGPL，BFD是GPL）。
由于libdwarf自身非常复杂，需要很多代码来操作。我这里不打算把所有代码贴出来，但你可以下载，然后自己编译运行。要编译这个文件，你需要安装libelf以及libdwarf，并在编译时为链接器提供-lelf以及-ldwarf标志。

这个演示程序接收一个可执行文件，并打印出程序中的函数名称同函数入口点地址。下面是本文用以演示的C程序产生的输出：

1
2
3
4
5
6
7

$ dwarf_get_func_addr tracedprog2
DW_TAG_subprogram: 'do_stuff'
low pc  : 0x08048604
high pc : 0x0804863e
DW_TAG_subprogram: 'main'
low pc  : 0x0804863e
high pc : 0x0804865a

libdwarf的文档非常好（见本文的参考文献部分），花点时间看看，对于本文中提到的DWARF段信息你处理起来就应该没什么问题了。

结论及下一步

调试信息只是一个简单的概念，具体实现细节可能相当复杂。但最终我们知道了调试器是如何从可执行文件中找出同源代码之间的关系。有了调试信息在手，调试器为用户所能识别的源代码和数据结构同可执行文件之间架起了一座桥。

本文加上之前的两篇文章总结了调试器内部的工作原理。通过这一系列文章，再加上一点编程工作就应该可以在Linux下创建一个具有基本功能的调试器。

至于下一步，我还不确定。也许我会就此终结这一系列文章，也许我会再写一些高级主题比如backtrace，甚至Windows系统上的调试。读者们也可以为今后这一系列文章提供意见和想法。不要客气，请随意在评论栏或通过Email给我提些建议吧。

调试器工作原理之二——实现断点

调试器工作原理之一——基础篇
调试器工作原理之二——实现断点
调试器工作原理之三——调试信息

本文的主要内容

这里我将说明调试器中的断点机制是如何实现的。断点机制是调试器的两大主要支柱之一 ——另一个是在被调试进程的内存空间中查看变量的值。我们已经在第一篇文章中稍微涉及到了一些监视被调试进程的知识，但断点机制仍然还是个迷。阅读完本文之后，这将不再是什么秘密了。

软中断

要在x86体系结构上实现断点我们要用到软中断（也称为“陷阱”trap）。在我们深入细节之前，我想先大致解释一下中断和陷阱的概念。

CPU有一个单独的执行序列，会一条指令一条指令的顺序执行。要处理类似IO或者硬件时钟这样的异步事件时CPU就要用到中断。硬件中断通常是一个 专门的电信号，连接到一个特殊的“响应电路”上。这个电路会感知中断的到来，然后会使CPU停止当前的执行流，保存当前的状态，然后跳转到一个预定义的地 址处去执行，这个地址上会有一个中断处理例程。当中断处理例程完成它的工作后，CPU就从之前停止的地方恢复执行。

软中断的原理类似，但实际上有一点不同。CPU支持特殊的指令允许通过软件来模拟一个中断。当执行到这个指令时，CPU将其当做一个中断——停止当 前正常的执行流，保存状态然后跳转到一个处理例程中执行。这种“陷阱”让许多现代的操作系统得以有效完成很多复杂任务（任务调度、虚拟内存、内存保护、调 试等）。 一些编程错误（比如除0操作）也被CPU当做一个“陷阱”，通常被认为是“异常”。这里软中断同硬件中断之间的界限就变得模糊了，因为这里很难说这种异常到底是硬件中断还是软中断引起的。我有些偏离主题了，让我们回到关于断点的讨论上来。

关于int 3指令

看过前一节后，现在我可以简单地说断点就是通过CPU的特殊指令——int 3来实现的。int就是x86体系结构中的“陷阱指令”——对预定义的中断处理例程的调用。x86支持int指令带有一个8位的操作数，用来指定所发生的 中断号。因此，理论上可以支持256种“陷阱”。前32个由CPU自己保留，这里第3号就是我们感兴趣的——称为“trap to debugger”。

不多说了，我这里就引用“圣经”中的原话吧（这里的圣经就是Intel’s Architecture software developer’s manual, volume2A）：
“INT 3指令产生一个特殊的单字节操作码（CC），这是用来调用调试异常处理例程的。（这个单字节形式非常有价值，因为这样可以通过一个断点来替换掉任何指令的第一个字节，包括其它的单字节指令也是一样，而不会覆盖到其它的操作码）。”

上面这段话非常重要，但现在解释它还是太早，我们稍后再来看。

使用int 3指令

是的，懂得事物背后的原理是很棒的，但是这到底意味着什么？我们该如何使用int 3来实现断点机制？套用常见的编程问答中出现的对话——请用代码说话！ 实际上这真的非常简单。一旦你的进程执行到int 3指令时，操作系统就将它暂停。在Linux上（本文关注的是Linux平台），这会给该进程发送一个SIGTRAP信号。

这就是全部——真的！现在回顾一下本系列文章的第一篇，跟踪（调试器）进程可以获得所有其子进程（或者被关联到的进程）所得到信号的通知，现在你知道我们该做什么了吧？ 就是这样，再没有什么计算机体系结构方面的东东了，该写代码了。

手动设定断点

现在我要展示如何在程序中设定断点。用于这个示例的目标程序如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

section  .text
  ; The _start symbol must be declared for the linker (ld)
  global _start
 
_start:
 
  ; Prepare arguments for the sys_write system call:
  ;   - eax: system call number (sys_write)
  ;   - ebx: file descriptor (stdout)
  ;   - ecx: pointer to string
  ;   - edx: string length
  mov edx, len1
  mov ecx, msg1
  mov ebx, 1
  mov eax, 4
 
  ; Execute the sys_write system call
  int 0x80
 
  ; Now print the other message
  mov edx, len2
  mov ecx, msg2
  mov ebx, 1
  mov eax, 4
  int 0x80
 
  ; Execute sys_exit
  mov eax, 1
  int 0x80
 
section   .data
 
msg1  db  'Hello,', 0xa
len1  equ $ - msg1
msg2  db  'world!', 0xa
len2  equ $ - msg2

我现在使用的是汇编语言，这是为了避免当使用C语言时涉及到的编译和符号的问题。上面列出的程序功能就是在一行中打印“Hello，”，然后在下一行中打印“world！”。这个例子与上一篇文章中用到的例子很相似。

我希望设定的断点位置应该在第一条打印之后，但恰好在第二条打印之前。我们就让断点打在第一个int 0×80指令之后吧，也就是mov edx, len2。首先，我需要知道这条指令对应的地址是什么。运行objdump –d：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

traced_printer2: file format elf32-i386
 
Sections:
Idx   Name    Size        VMA         LMA         File off    Algn
  0   .text   00000033    08048080    08048080    00000080    2**4
          CONTENTS,ALLOC,LOAD,READONLY,CODE
  1   .data   0000000e    080490b4    080490b4    000000b4    2**2
          CONTENTS,ALLOC,LOAD,DATA
 
Disassembly of section .text:
 
08048080 <.text>:
 8048080: ba 07 00 00 00      mov     $0x7,%edx
 8048085: b9 b4 90 04 08      mov     $0x80490b4,%ecx
 804808a: bb 01 00 00 00      mov     $0x1,%ebx
 804808f: b8 04 00 00 00      mov     $0x4,%eax
 8048094: cd 80               int     $0x80
 8048096: ba 07 00 00 00      mov     $0x7,%edx
 804809b: b9 bb 90 04 08      mov     $0x80490bb,%ecx
 80480a0: bb 01 00 00 00      mov     $0x1,%ebx
 80480a5: b8 04 00 00 00      mov     $0x4,%eax
 80480aa: cd 80               int     $0x80
 80480ac: b8 01 00 00 00      mov     $0x1,%eax
 80480b1: cd 80               int     $0x80

通过上面的输出，我们知道要设定的断点地址是0×8048096。等等，真正的调试器不是像这样工作的，对吧？真正的调试器可以根据代码行数或者函 数名称来设定断点，而不是基于什么内存地址吧？非常正确。但是我们离那个标准还差的远——如果要像真正的调试器那样设定断点，我们还需要涵盖符号表以及调 试信息方面的知识，这需要用另一篇文章来说明。至于现在，我们还必须得通过内存地址来设定断点。

看到这里我真的很想再扯一点题外话，所以你有两个选择。如果你真的对于为什么地址是0×8048096，以及这代表什么意思非常感兴趣的话，接着看下一节。如果你对此毫无兴趣，只是想看看怎么设定断点，可以略过这一部分。

题外话——进程地址空间以及入口点

坦白的说，0×8048096本身并没有太大意义，这只不过是相对可执行镜像的代码段（text section）开始处的一个偏移量。如果你仔细看看前面objdump出来的结果，你会发现代码段的起始位置是0×08048080。这告诉了操作系统 要将代码段映射到进程虚拟地址空间的这个位置上。在Linux上，这些地址可以是绝对地址（比如，有的可执行镜像加载到内存中时是不可重定位的），因为在 虚拟内存系统中，每个进程都有自己独立的内存空间，并把整个32位的地址空间都看做是属于自己的（称为线性地址）。

如果我们通过readelf工具来检查可执行文件的ELF头，我们将得到如下输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$ readelf -h traced_printer2
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                              ELF32
  Data:                                   2's complement, little endian
  Version:                                1 (current)
  OS/ABI:                             UNIX - System V
  ABI Version:                            0
  Type:                                   EXEC (Executable file)
  Machine:                                Intel 80386
  Version:                                0x1
  Entry point address:                    0x8048080
  Start of program headers:               52 (bytes into file)
  Start of section headers:               220 (bytes into file)
  Flags:                              0x0
  Size of this header:                    52 (bytes)
  Size of program headers:                32 (bytes)
  Number of program headers:          2
  Size of section headers:                40 (bytes)
  Number of section headers:          4
  Section header string table index:  3

注意，ELF头的“entry point address”同样指向的是0×8048080。因此，如果我们把ELF文件中的这个部分解释给操作系统的话，就表示：
1. 将代码段映射到地址0×8048080处
2. 从入口点处开始执行——地址0×8048080
但是，为什么是0×8048080呢？它的出现是由于历史原因引起的。每个进程的地址空间的前128MB被保留给栈空间了（注：这一部分原因可参考 Linkers and Loaders）。128MB刚好是0×80000000，可执行镜像中的其他段可以从这里开始。0×8048080是Linux下的链接器ld所使用的 默认入口点。这个入口点可以通过传递参数-Ttext给ld来进行修改。

因此，得到的结论是这个地址并没有什么特别的，我们可以自由地修改它。只要ELF可执行文件的结构正确且在ELF头中的入口点地址同程序代码段（text section）的实际起始地址相吻合就OK了。

通过int 3指令在调试器中设定断点

要在被调试进程中的某个目标地址上设定一个断点，调试器需要做下面两件事情：
1. 保存目标地址上的数据
2. 将目标地址上的第一个字节替换为int 3指令
然后，当调试器向操作系统请求开始运行进程时（通过前一篇文章中提到的PTRACE_CONT），进程最终一定会碰到int 3指令。此时进程停止，操作系统将发送一个信号。这时就是调试器再次出马的时候了，接收到一个其子进程（或被跟踪进程）停止的信号，然后调试器要做下面几 件事：
1. 在目标地址上用原来的指令替换掉int 3
2. 将被跟踪进程中的指令指针向后递减1。这么做是必须的，因为现在指令指针指向的是已经执行过的int 3之后的下一条指令。
3. 由于进程此时仍然是停止的，用户可以同被调试进程进行某种形式的交互。这里调试器可以让你查看变量的值，检查调用栈等等。
4. 当用户希望进程继续运行时，调试器负责将断点再次加到目标地址上（由于在第一步中断点已经被移除了），除非用户希望取消断点。
让我们看看这些步骤如何转化为实际的代码。我们将沿用第一篇文章中展示过的调试器“模版”（fork一个子进程，然后对其跟踪）。无论如何，本文结尾处会给出完整源码的链接。

1
2
3
4
5
6
7
8

/* Obtain and show child's instruction pointer */
ptrace(PTRACE_GETREGS, child_pid, 0, ®s);
procmsg("Child started. EIP = 0x%08x\n", regs.eip);
 
/* Look at the word at the address we're interested in */
unsigned addr = 0x8048096;
unsigned data = ptrace(PTRACE_PEEKTEXT, child_pid, (void*)addr, 0);
procmsg("Original data at 0x%08x: 0x%08x\n", addr, data);

这里调试器从被跟踪进程中获取到指令指针，然后检查当前位于地址0×8048096处的字长内容。运行本文前面列出的汇编码程序，将打印出：

1
2

[13028] Child started. EIP = 0x08048080
[13028] Original data at 0x08048096: 0x000007ba

目前为止一切顺利，下一步：

1
2
3
4
5
6
7

/* Write the trap instruction 'int 3' into the address */
unsigned data_with_trap = (data & 0xFFFFFF00) | 0xCC;
ptrace(PTRACE_POKETEXT, child_pid, (void*)addr, (void*)data_with_trap);
 
/* See what's there again... */
unsigned readback_data = ptrace(PTRACE_PEEKTEXT, child_pid, (void*)addr, 0);
procmsg("After trap, data at 0x%08x: 0x%08x\n", addr, readback_data);

注意看我们是如何将int 3指令插入到目标地址上的。这部分代码将打印出：

1

[13028] After trap, data at 0x08048096: 0x000007cc

再一次如同预计的那样——0xba被0xcc取代了。调试器现在运行子进程然后等待子进程在断点处停止住。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/* Let the child run to the breakpoint and wait for it to
** reach it
*/
ptrace(PTRACE_CONT, child_pid, 0, 0);
 
wait(&wait_status);
if (WIFSTOPPED(wait_status)) {
	procmsg("Child got a signal: %s\n", strsignal(WSTOPSIG(wait_status)));
}
else {
	perror("wait");
	return;
}
 
/* See where the child is now */
ptrace(PTRACE_GETREGS, child_pid, 0, ®s);
procmsg("Child stopped at EIP = 0x%08x\n", regs.eip);

这段代码打印出：

1
2
3

Hello,
[13028] Child got a signal: Trace/breakpoint trap
[13028] Child stopped at EIP = 0x08048097

注意，“Hello,”在断点之前打印出来了——同我们计划的一样。同时我们发现子进程已经停止运行了——就在这个单字节的陷阱指令执行之后。

1
2
3
4
5
6
7
8
9
10
11

/* Remove the breakpoint by restoring the previous data
** at the target address, and unwind the EIP back by 1 to
** let the CPU execute the original instruction that was
** there.
*/
ptrace(PTRACE_POKETEXT, child_pid, (void*)addr, (void*)data);
regs.eip -= 1;
ptrace(PTRACE_SETREGS, child_pid, 0, ®s);
 
/* The child can continue running now */
ptrace(PTRACE_CONT, child_pid, 0, 0);

这会使子进程打印出“world！”然后退出，同之前计划的一样。
注意，我们这里并没有重新加载断点。这可以在单步模式下执行，然后将陷阱指令加回去，再做PTRACE_CONT就可以了。本文稍后介绍的debug库实现了这个功能。

更多关于int 3指令

现在是回过头来说说int 3指令的好机会，以及解释一下Intel手册中对这条指令的奇怪说明。

“这个单字节形式非常有价值，因为这样可以通过一个断点来替换掉任何指令的第一个字节，包括其它的单字节指令也是一样，而不会覆盖到其它的操作码。”

x86架构上的int指令占用2个字节——0xcd加上中断号。int 3的二进制形式可以被编码为cd 03，但这里有一个特殊的单字节指令0xcc以同样的作用而被保留。为什么要这样做呢？因为这允许我们在插入一个断点时覆盖到的指令不会多于一条。这很重 要，考虑下面的示例代码：

1
2
3
4
5
6

.. some code ..
  jz  foo
  dec eax
foo:
  call    bar
  .. some code ..

假设我们要在dec eax上设定断点。这恰好是条单字节指令（操作码是0×48）。如果替换为断点的指令长度超过1字节，我们就被迫改写了接下来的下一条指令（call）， 这可能会产生一些完全非法的行为。考虑一下条件分支jz foo，这时进程可能不会在dec eax处停止下来（我们在此设定的断点，改写了原来的指令），而是直接执行了后面的非法指令。

通过对int 3指令采用一个特殊的单字节编码就能解决这个问题。因为x86架构上指令最短的长度就是1字节，这样我们可以保证只有我们希望停止的那条指令被修改。

封装细节

前面几节中的示例代码展示了许多底层的细节，这些可以很容易地通过API进行封装。我已经做了一些封装，使其成为一个小型的调试库——debuglib。代码在本文末尾处可以下载。这里我只想介绍下它的用法，我们要开始调试C程序了。

跟踪C程序

目前为止为了简单起见我把重点放在对汇编程序的跟踪上了。现在升一级来看看我们该如何跟踪一个C程序。
其实事情并没有很大的不同——只是现在有点难以找到放置断点的位置。考虑如下这个简单的C程序:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <stdio.h>
 
void do_stuff()
{
	printf("Hello, ");
}
 
int main()
{
	for (int i = 0; i < 4; ++i)
		do_stuff();
	printf("world!\n");
	return 0;
}

假设我想在do_stuff的入口处设置一个断点。我将请出我们的老朋友objdump来反汇编可执行文件，但得到的输出太多。其实，查看text 段不太管用，因为这里面包含了大量的初始化C运行时库的代码，我目前对此并不感兴趣。所以，我们只需要在dump出来的结果里看do_stuff部分就好 了。

1
2
3
4
5
6
7
8

080483e4 <do_stuff>:
 80483e4: 55                      push    %ebp
 80483e5: 89 e5                   mov     %esp,%ebp
 80483e7: 83 ec 18                sub     $0x18,%esp
 80483ea: c7 04 24 f0 84 04 08    movl    $0x80484f0,(%esp)
 80483f1: e8 22 ff ff ff          call    8048318 <puts@plt>
 80483f6: c9                      leave
 80483f7: c3                      ret

好的，所以我们应该把断点设定在0x080483e4上，这是do_stuff的第一条指令。另外，由于这个函数是在循环体中调用的，我们希望在循 环全部结束前保留断点，让程序可以在每一轮循环中都在断点处停下。我将使用debuglib来简化代码编写。这里是完整的调试器函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

void run_debugger(pid_t child_pid)
{
	procmsg("debugger started\n");
 
	/* Wait for child to stop on its first instruction */
	wait(0);
	procmsg("child now at EIP = 0x%08x\n", get_child_eip(child_pid));
 
	/* Create breakpoint and run to it*/
	debug_breakpoint* bp = create_breakpoint(child_pid, (void*)0x080483e4);
	procmsg("breakpoint created\n");
	ptrace(PTRACE_CONT, child_pid, 0, 0);
	wait(0);
 
	/* Loop as long as the child didn't exit */
	while (1) {
		/* The child is stopped at a breakpoint here. Resume its
		** execution until it either exits or hits the
		** breakpoint again.
		*/
		procmsg("child stopped at breakpoint. EIP = 0x%08X\n", get_child_eip(child_pid));
		procmsg("resuming\n");
		int rc = resume_from_breakpoint(child_pid, bp);
 
		if (rc == 0) {
			procmsg("child exited\n");
			break;
		}
		else if (rc == 1) {
			continue;
		}
		else {
			procmsg("unexpected: %d\n", rc);
			break;
		}
	}
 
	cleanup_breakpoint(bp);
}

我们不用手动修改EIP指针以及目标进程的内存空间，我们只需要通过create_breakpoint, resume_from_breakpoint以及cleanup_breakpoint来操作就可以了。我们来看看当跟踪这个简单的C程序后的打印输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ bp_use_lib traced_c_loop
[13363] debugger started
[13364] target started. will run 'traced_c_loop'
[13363] child now at EIP = 0x00a37850
[13363] breakpoint created
[13363] child stopped at breakpoint. EIP = 0x080483E5
[13363] resuming
Hello,
[13363] child stopped at breakpoint. EIP = 0x080483E5
[13363] resuming
Hello,
[13363] child stopped at breakpoint. EIP = 0x080483E5
[13363] resuming
Hello,
[13363] child stopped at breakpoint. EIP = 0x080483E5
[13363] resuming
Hello,
world!
[13363] child exited

跟预计的情况一模一样！

代码

这里是完整的源码。在文件夹中你会发现：
debuglib.h以及debuglib.c——封装了调试器的一些内部工作。
bp_manual.c —— 本文一开始介绍的“手动”式设定断点。用到了debuglib库中的一些样板代码。
bp_use_lib.c—— 大部分代码用到了debuglib，这就是本文中用于说明跟踪一个C程序中的循环的示例代码。

结论及下一步要做的

我们已经涵盖了如何在调试器中实现断点机制。尽管实现细节根据操作系统的不同而有所区别，但只要你使用的是x86架构的处理器，那么一切变化都基于相同的主题——在我们希望停止的指令上将其替换为int 3。
我敢肯定，有些读者就像我一样，对于通过指定原始地址来设定断点的做法不会感到很激动。我们更希望说“在do_stuff上停住”，甚至是“在do_stuff的这一行上停住”，然后调试器就能照办。在下一篇文章中，我将向您展示这是如何做到的。