Debug实现原理

https://tpaschalis.github.io/delve-debugging/
https://jiajunhuang.com/articles/2020_04_23-go_gdb.md.html

一般是在IDE里代码中加断点，一步步跟踪。然后观察变量的值，观察输出等等。
这种在Debug工具，许多IDE中都有提供，像Eclipse, IDEA,NetBeans，甚至我们可以直接使用JDK自带的jdb工具进行高度。这些工具都支持本地调试和远程调试。

那在我们加断点，debug，单步调试等一系列动作背后，是如何实现的呢？

不得不提JPDA(Java Platform Debugger Architecture)。我们每次使用的debug功能，都是靠JPDA的支撑实现的。

什么是JPDA?

官方文档里这样介绍：

The Java Platform Debugger Architecture (JPDA) consists of three interfaces designed for use by debuggers in development environments for desktop systems.

我们看到，JPDA由三部分组成：

JVMTI(Java Virtual Machine Tool Interface)

JDWP(Java Debugger Wire Protocol)

JDI(Java Debug Interface)

熟悉JVM的朋友可能听说过JVMPI和JVMDI，在JDK1.5他们统一被替换为JVMTI。

JVMTI

以前的文章里我们提到过Class的hotSwap，就是通过Instrument实现class的redefine和retransform。
而本质上JVMTI是一个programming interface，主要用在开发和监控上。而且它提供了接口去观察(inspect) 应用状态和控制应用的执行。工具通过它提供的接口，可以进行如下功能的实现：

profiling

debuging

monitoring

thread analysis

coverage analysis

可以看到，我们使用到的debug，只是JVMTI提供的众从能力中的一种。

JDWP

观察过Java debug进程的同学也许有印象，以debug方式启动的JVM进程，看起来是这样的：

-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:63971,server=y,suspend=n

除了进程名之外，还在启动参数里包含agentlib:jdwp这些。这个就是现在要介绍的JDWP。

什么是JDWP?
Java Debug Wire Protocol，是debugger和它要debug的JVM之间进行通讯的协议。更多具体协议的细节这里不介绍，感兴趣的同学可以到这儿查看：

Command Packet
Header
length (4 bytes)
id (4 bytes)
flags (1 byte)
command set (1 byte)
command (1 byte)
data (Variable)
Reply Packet
Header
length (4 bytes)
id (4 bytes)
flags (1 byte)
error code (2 bytes)
data (Variable)

http://docs.oracle.com/javase/6/docs/technotes/guides/jpda/jdwp-spec.html

注意，这仅仅是一个协议的格式，具体的传输实现不是由JDWP来实现的。我们的debugger执行的操作发送到JDWP的实现上，然后再转给JVMTI来具体控制。

JDI

JDI是三个模块中最高层的一个接口，通过JDI，debugger可以更方便的编写符合JDWP格式的数据，用来进行调试数据传输。JDI的引入，提高了开发debugger的效率。

所以，从整体上看，我们可以把JPDA看作一个两个互相通讯的程序，所以我们可以在任意地点很方便的调试另一个JVM上运行的程序。

我们每次在IDE里进行代码调试时，实质上是通过IDE里的debugger这个界面执行GUI操作，然后通过JDI发送数据到JDWP，再经过JVMTI最终实现程序的高度。

每次我们打开IDE调试一个Java应用的时候，或者远程attach一个Java进程的时候，别忘了这个IDE背后的身影—JPDA。

PS:Tomcat启动脚本中也直接包含了debug方式启动的功能，在命令行中输入

catalina jpda start， Tomcat就以debug方式启动了。

对于想了解源码但不想把源码以项目形式运行的同学，可以采用这种方式，然后使用远程调试的方式，把源码所在项目和这个attach起来就可以了。

在【java】里，有JVM的存在，可以省好多事，分三层

　　1.JVMIT【虚拟机接口】，底层

　　2.JDWP【虚拟机传输协议，格式】，中间传输

　　3.JDI【程序调试接口】，发送指令控制接口
　　
https://www.ibm.com/developerworks/cn/java/j-lo-jpda1/

Java 虚拟机工具接口（JVMTI）
JVMTI（Java Virtual Machine Tool Interface）即指 Java 虚拟机工具接口，它是一套由虚拟机直接提供的 native 接口，它处于整个 JPDA 体系的最底层，所有调试功能本质上都需要通过 JVMTI 来提供。通过这些接口，开发人员不仅调试在该虚拟机上运行的 Java 程序，还能查看它们运行的状态，设置回调函数，控制某些环境变量，从而优化程序性能。我们知道，JVMTI 的前身是 JVMDI 和 JVMPI，它们原来分别被用于提供调试 Java 程序以及 Java 程序调节性能的功能。在 J2SE 5.0 之后 JDK 取代了 JVMDI 和 JVMPI 这两套接口，JVMDI 在最新的 Java SE 6 中已经不提供支持，而 JVMPI 也计划在 Java SE 7 后被彻底取代。

Java 调试线协议（JDWP）
JDWP（Java Debug Wire Protocol）是一个为 Java 调试而设计的一个通讯交互协议，它定义了调试器和被调试程序之间传递的信息的格式。在 JPDA 体系中，作为前端（front-end）的调试者（debugger）进程和后端（back-end）的被调试程序（debuggee）进程之间的交互数据的格式就是由 JDWP 来描述的，它详细完整地定义了请求命令、回应数据和错误代码，保证了前端和后端的 JVMTI 和 JDI 的通信通畅。比如在 Sun 公司提供的实现中，它提供了一个名为 jdwp.dll（jdwp.so）的动态链接库文件，这个动态库文件实现了一个 Agent，它会负责解析前端发出的请求或者命令，并将其转化为 JVMTI 调用，然后将 JVMTI 函数的返回值封装成 JDWP 数据发还给后端。

另外，这里需要注意的是 JDWP 本身并不包括传输层的实现，传输层需要独立实现，但是 JDWP 包括了和传输层交互的严格的定义，就是说，JDWP 协议虽然不规定我们是通过 EMS 还是快递运送货物的，但是它规定了我们传送的货物的摆放的方式。在 Sun 公司提供的 JDK 中，在传输层上，它提供了 socket 方式，以及在 Windows 上的 shared memory 方式。当然，传输层本身无非就是本机内进程间通信方式和远端通信方式，用户有兴趣也可以按 JDWP 的标准自己实现。

Java 调试接口（JDI）
JDI（Java Debug Interface）是三个模块中最高层的接口，在多数的 JDK 中，它是由 Java 语言实现的。 JDI 由针对前端定义的接口组成，通过它，调试工具开发人员就能通过前端虚拟机上的调试器来远程操控后端虚拟机上被调试程序的运行，JDI 不仅能帮助开发人员格式化 JDWP 数据，而且还能为 JDWP 数据传输提供队列、缓存等优化服务。从理论上说，开发人员只需使用 JDWP 和 JVMTI 即可支持跨平台的远程调试，但是直接编写 JDWP 程序费时费力，而且效率不高。因此基于 Java 的 JDI 层的引入，简化了操作，提高了开发人员开发调试程序的效率。

对于远端的调试，GDB 也没有很好的默认实现，当然，C/C++ 在这方面也没有特别大的需求。

https://www.cnblogs.com/alantu2018/p/8997173.html
调试器工作原理（1）：基础篇

Linux下的调试器实现的主要组成部分——ptrace系统调用。
然后对其进行调试，或者将自己本身关联到一个已存在的进程之上。它可以单步运行代码，设置断点然后运行程序，检查变量的值以及跟踪调用栈。许多调试器已经拥有了一些高级特性，比如执行表达式并在被调试进程的地址空间中调用函数，甚至可以直接修改进程的代码并观察修改后的程序行为。

尽管现代的调试器都是复杂的大型程序，但令人惊讶的是构建调试器的基础确是如此的简单。调试器只用到了几个由操作系统以及编译器/链接器提供的基础服务，剩下的仅仅就是简单的编程问题了。

Linux下的调试——ptrace

Linux下调试器拥有一个瑞士军刀般的工具，这就是ptrace系统调用。这是一个功能众多且相当复杂的工具，能允许一个进程控制另一个进程的运行，而且可以监视和渗入到进程内部。ptrace本身需要一本中等篇幅的书才能对其进行完整的解释，这就是为什么我只打算通过例子把重点放在它的实际用途上。让我们继续深入探寻。

遍历进程的代码

我现在要写一个在“跟踪”模式下运行的进程的例子，这里我们要单步遍历这个进程的代码——由CPU所执行的机器码（汇编指令）。我会在这里给出例子代码，解释每个部分，本文结尾处你可以通过链接下载一份完整的C程序文件，可以自行编译执行并研究。从高层设计来说，我们要写一个程序，它产生一个子进程用来执行一个用户指定的命令，而父进程跟踪这个子进程。首先，main函数是这样的：

int main(int argc, char** argv)
{
pid_t child_pid;

if (argc < 2) {

    fprintf(stderr, "Expected a program name as argument\n");

    return -1;

}

 

child_pid = fork();

if (child_pid == 0)

    run_target(argv[1]);

else if (child_pid > 0)

    run_debugger(child_pid);

else {

    perror("fork");

    return -1;

}

 

return 0; }

代码相当简单，我们通过fork产生一个新的子进程。随后的if语句块处理子进程（这里称为“目标进程”），而else if语句块处理父进程（这里称为“调试器”）。下面是目标进程：

void run_target(const char* programname)
{
procmsg(“target started. will run ‘%s’\n”, programname);

/* Allow tracing of this process */

if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {

    perror("ptrace");

    return;

}

 

/* Replace this process's image with the given program */

execl(programname, programname, 0); } 这部分最有意思的地方在ptrace调用。ptrace的原型是（在sys/ptrace.h）：

long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);

第一个参数是request，可以是预定义的以PTRACE_打头的常量值。第二个参数指定了进程id，第三以及第四个参数是地址和指向数据的指针，用来对内存做操作。上面代码段中的ptrace调用使用了PTRACE_TRACEME请求，这表示这个子进程要求操作系统内核允许它的父进程对其跟踪。这个请求在man手册中解释的非常清楚：

“表明这个进程由它的父进程来跟踪。任何发给这个进程的信号（除了SIGKILL）将导致该进程停止运行，而它的父进程会通过wait()获得通知。另外，该进程之后所有对exec()的调用都将使操作系统产生一个SIGTRAP信号发送给它，这让父进程有机会在新程序开始执行之前获得对子进程的控制权。如果不希望由父进程来跟踪的话，那就不应该使用这个请求。（pid、addr、data被忽略）”

我已经把这个例子中我们感兴趣的地方高亮显示了。注意，run_target在ptrace调用之后紧接着做的是通过execl来调用我们指定的程序。这里就会像我们高亮显示的部分所解释的那样，操作系统内核会在子进程开始执行execl中指定的程序之前停止该进程，并发送一个信号给父进程。

因此，是时候看看父进程需要做些什么了：

void run_debugger(pid_t child_pid)
{
int wait_status;
unsigned icounter = 0;
procmsg(“debugger started\n”);

/* Wait for child to stop on its first instruction */

wait(&wait_status);

 

while (WIFSTOPPED(wait_status)) {

    icounter++;

    /* Make the child execute another instruction */

    if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {

        perror("ptrace");

        return;

    }

 

    /* Wait for child to stop on its next instruction */

    wait(&wait_status);

}

 

procmsg("the child executed %u instructions\n", icounter); } 通过上面的代码我们可以回顾一下，一旦子进程开始执行exec调用，它就会停止然后接收到一个SIGTRAP信号。父进程通过第一个wait调用正在等待这个事件发生。一旦子进程停止（如果子进程由于发送的信号而停止运行，WIFSTOPPED就返回true），父进程就去检查这个事件。

父进程接下来要做的是本文中最有意思的地方。父进程通过PTRACE_SINGLESTEP以及子进程的id号来调用ptrace。这么做是告诉操作系统——请重新启动子进程，但当子进程执行了下一条指令后再将其停止。然后父进程再次等待子进程的停止，整个循环继续得以执行。当从wait中得到的不是关于子进程停止的信号时，循环结束。在正常运行这个跟踪程序时，会得到子进程正常退出（WIFEXITED会返回true）的信号。

icounter会统计子进程执行的指令数量。因此我们这个简单的例子实际上还是做了点有用的事情——通过在命令行上指定一个程序名，我们的例子会执行这个指定的程序，然后统计出从开始到结束该程序执行过的CPU指令总数。让我们看看实际运行的情况。

实际测试

我编译了下面这个简单的程序，然后在我们的跟踪程序下执行：

#include
int main()
{
printf(“Hello, world!\n”);
return 0;
}
令我惊讶的是，我们的跟踪程序运行了很长的时间然后报告显示一共有超过100000条指令得到了执行。仅仅只是一个简单的printf调用，为什么会这样？答案非常有意思。默认情况下，Linux中的gcc编译器会动态链接到C运行时库。这意味着任何程序在运行时首先要做的事情是加载动态库。这需要很多代码实现——记住，我们这个简单的跟踪程序会针对每一条被执行的指令计数，不仅仅是main函数，而是整个进程。

因此，当我采用-static标志静态链接这个测试程序时（注意到可执行文件因此增加了500KB的大小，因为它静态链接了C运行时库），我们的跟踪程序报告显示只有7000条左右的指令被执行了。这还是非常多，但如果你了解到libc的初始化工作仍然先于main的执行，而清理工作会在main之后执行，那么这就完全说得通了。而且，printf也是一个复杂的函数。

我们还是不满足于此，我希望能看到一些可检测的东西，例如我可以从整体上看到每一条需要被执行的指令是什么。这一点我们可以通过汇编代码来得到。因此我把这个“Hello，world”程序汇编（gcc -S）为如下的汇编码：

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, len

mov    ecx, msg

mov    ebx, 1

mov    eax, 4

 

; Execute the sys_write system call

int    0x80

 

; Execute sys_exit

mov    eax, 1

int    0x80

section .data
msg db ‘Hello, world!’, 0xa
len equ $ - msg
这就足够了。现在跟踪程序会报告有7条指令得到了执行，我可以很容易地从汇编代码来验证这一点。

深入指令流

汇编码程序得以让我为大家介绍ptrace的另一个强大的功能——详细检查被跟踪进程的状态。下面是run_debugger函数的另一个版本：

void run_debugger(pid_t child_pid)
{
int wait_status;
unsigned icounter = 0;
procmsg(“debugger started\n”);

/* Wait for child to stop on its first instruction */

wait(&wait_status);

 

while (WIFSTOPPED(wait_status)) {

    icounter++;

    struct user_regs_struct regs;

    ptrace(PTRACE_GETREGS, child_pid, 0, ®s);

    unsigned instr = ptrace(PTRACE_PEEKTEXT, child_pid, regs.eip, 0);

 

    procmsg("icounter = %u.  EIP = 0x%08x.  instr = 0x%08x\n",

                icounter, regs.eip, instr);

 

    /* Make the child execute another instruction */

    if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {

        perror("ptrace");

        return;

    }

 

    /* Wait for child to stop on its next instruction */

    wait(&wait_status);

}

 

procmsg("the child executed %u instructions\n", icounter); } 同前个版本相比，唯一的不同之处在于while循环的开始几行。这里有两个新的ptrace调用。第一个读取进程的寄存器值到一个结构体中。结构体user_regs_struct定义在sys/user.h中。这儿有个有趣的地方——如果你打开这个头文件看看，靠近文件顶端的地方有一条这样的注释：

/* 本文件的唯一目的是为GDB，且只为GDB所用。对于这个文件，不要看的太多。除了GDB以外不要用于任何其他目的，除非你知道你正在做什么。*/

现在，我不知道你是怎么想的，但我感觉我们正处于正确的跑道上。无论如何，回到我们的例子上来。一旦我们将所有的寄存器值获取到regs中，我们就可以通过PTRACE_PEEKTEXT标志以及将regs.eip（x86架构上的扩展指令指针）做参数传入ptrace来调用。我们所得到的就是指令。让我们在汇编代码上运行这个新版的跟踪程序。

$ simple_tracer traced_helloworld
[5700] debugger started
[5701] target started. will run ‘traced_helloworld’
[5700] icounter = 1. EIP = 0x08048080. instr = 0x00000eba
[5700] icounter = 2. EIP = 0x08048085. instr = 0x0490a0b9
[5700] icounter = 3. EIP = 0x0804808a. instr = 0x000001bb
[5700] icounter = 4. EIP = 0x0804808f. instr = 0x000004b8
[5700] icounter = 5. EIP = 0x08048094. instr = 0x01b880cd
Hello, world!
[5700] icounter = 6. EIP = 0x08048096. instr = 0x000001b8
[5700] icounter = 7. EIP = 0x0804809b. instr = 0x000080cd
[5700] the child executed 7 instructions

OK，所以现在除了icounter以外，我们还能看到指令指针以及每一步的指令。如何验证这是否正确呢？可以通过在可执行文件上执行objdump –d来实现：

$ objdump -d traced_helloworld

traced_helloworld: file format elf32-i386

Disassembly of section .text:

08048080 <.text>:
8048080: ba 0e 00 00 00 mov $0xe,%edx
8048085: b9 a0 90 04 08 mov $0x80490a0,%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: b8 01 00 00 00 mov $0x1,%eax
804809b: cd 80 int $0x80

用这份输出对比我们的跟踪程序输出，应该很容易观察到相同的地方。

关联到运行中的进程上

你已经知道了调试器也可以关联到已经处于运行状态的进程上。看到这里，你应该不会感到惊讶，这也是通过ptrace来实现的。这需要通过PTRACE_ATTACH请求。这里我不会给出一段样例代码，因为通过我们已经看到的代码，这应该很容易实现。基于教学的目的，这里采用的方法更为便捷（因为我们可以在子进程刚启动时立刻将它停止）。

代码

本文给出的这个简单的跟踪程序的完整代码（更高级一点，可以将具体指令打印出来）可以在这里找到。程序通过-Wall –pedantic –std=c99编译选项在4.4版的gcc上编译。

结论及下一步要做的

诚然，本文并没有涵盖太多的内容——我们离一个真正可用的调试器还差的很远。但是，我希望这篇文章至少已经揭开了调试过程的神秘面纱。ptrace是一个拥有许多功能的系统调用，目前我们只展示了其中少数几种功能。

能够单步执行代码是很有用处的，但作用有限。以“Hello， world”为例，要到达main函数，需要先遍历好几千条初始化C运行时库的指令。这就不太方便了。我们所希望的理想方案是可以在main函数入口处设置一个断点，从断点处开始单步执行。下一篇文章中我将向您展示该如何实现断点机制。

http://www.linuxjournal.com/article/6100?page=0,1
https://linuxgazette.net/81/sandeep.html
http://www.alexonlinux.com/how-debugger-works

调试器工作原理（2）：实现断点
本文是关于调试器工作原理探究系列的第二篇。在开始阅读本文前，请先确保你已经读过本系列的第一篇（基础篇）。

本文的主要内容

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

软中断

要在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信号。

这就是全部——真的！现在回顾一下本系列文章的第一篇，跟踪（调试器）进程可以获得所有其子进程（或者被关联到的进程）所得到信号的通知，现在你知道我们该做什么了吧？

就是这样，再没有什么计算机体系结构方面的东东了，该写代码了。

手动设定断点

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

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 0x80指令之后吧，也就是mov edx, len2。首先，我需要知道这条指令对应的地址是什么。运行objdump –d：

traced_printer2: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000033 08048080 08048080 00000080 24
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0000000e 080490b4 080490b4 000000b4 22
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

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

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

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

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

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

$ 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”同样指向的是0x8048080。因此，如果我们把ELF文件中的这个部分解释给操作系统的话，就表示：

1. 
   

   将代码段映射到地址0x8048080处

   
   


2. 
   

   从入口点处开始执行——地址0x8048080

   
   

但是，为什么是0x8048080呢？它的出现是由于历史原因引起的。每个进程的地址空间的前128MB被保留给栈空间了（注：这一部分原因可参考Linkers and Loaders）。128MB刚好是0x80000000，可执行镜像中的其他段可以从这里开始。0x8048080是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一个子进程，然后对其跟踪）。无论如何，本文结尾处会给出完整源码的链接。

/* 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);

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

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

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

/* 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指令插入到目标地址上的。这部分代码将打印出：

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

再一次如同预计的那样——0xba被0xcc取代了。调试器现在运行子进程然后等待子进程在断点处停止住。
/* 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);

这段代码打印出：
Hello,
[13028] Child got a signal: Trace/breakpoint trap
[13028] Child stopped at EIP = 0x08048097

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

/* 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以同样的作用而被保留。为什么要这样做呢？因为这允许我们在插入一个断点时覆盖到的指令不会多于一条。这很重要，考虑下面的示例代码：

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

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

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

封装细节

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

跟踪C程序

目前为止为了简单起见我把重点放在对汇编程序的跟踪上了。现在升一级来看看我们该如何跟踪一个C程序。

其实事情并没有很大的不同——只是现在有点难以找到放置断点的位置。考虑如下这个简单的C程序:

#include

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部分就好了。
080483e4 :
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来简化代码编写。这里是完整的调试器函数：
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程序后的打印输出：

$ 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的这一行上停住”，然后调试器就能照办。在下一篇文章中，我将向您展示这是如何做到的。

调试器工作原理（3）：调试信息
本文是调试器工作原理探究系列的第三篇，在阅读前请先确保已经读过本系列的第一和第二篇。

本篇主要内容

在本文中我将向大家解释关于调试器是如何在机器码中寻找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的可执行文件来做下实验。

#include

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格式的调试段：
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。

我们运行

objdump –dwarf=info traceprog2

得到的输出非常长，对于这个例子，我们只用关注这几行就可以了：
<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>: Abbrev Number: 9 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : (...): main
DW_AT_decl_file : 1
DW_AT_decl_line : 14
DW_AT_type : <0x4b>
DW_AT_low_pc : 0x804863e
DW_AT_high_pc : 0x804865a