调试器原理_调试器的工作原理

调试器原理

调试器是大多数（如果不是每种）开发人员在软件工程生涯中至少使用一次的软件之一，但是你们当中有多少人知道它们的实际工作原理？ 在悉尼举行的linux.conf.au 2018上的演讲中，我将谈论从头开始编写调试器...在Rust中 ！

在本文中，术语调试器/跟踪器是可互换的。 “跟踪”是指跟踪程序正在跟踪的进程。

ptrace系统调用

大多数调试器严重依赖于称为ptrace(2)的系统调用，该系统调用具有以下原型：

   
   

    
    

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

这是一个系统调用，可以处理流程的几乎所有方面。 但是，在调试器可以附加到进程之前，“ tracee”必须使用请求PTRACE_TRACEME调用ptrace 。 这告诉Linux，父进程通过ptrace附加到此进程是合法的。 但是...我们如何强迫一个进程调用ptrace ？ 十分简单！ fork/execve提供了一种在fork之后但在tracee真正开始使用execve之前调用ptrace的简便方法。 方便地， fork也将返回tracee的pid ，这是以后使用ptrace所必需的。

现在，调试器可以跟踪该跟踪，进行了重要的更改：

• 每次将信号传递到跟踪时，它都会停止，并且将等待事件传递到跟踪器，该事件可以由wait的系统调用系列捕获。
• 每个execve系统调用都将导致SIGTRAP被传递给Tracee。 （与之前的项目相结合，这意味着之前的tracee停止execve可以充分利用的地方。）

这意味着，一旦我们发出PTRACE_TRACEME请求并调用execve系统调用以在跟踪中实际启动程序，由于execve传递了SIGTRAP ，并且跟踪器中的等待事件捕获了该跟踪，所以该跟踪将立即停止。 我们如何继续？ 正如人们所期望的那样， ptrace有许多请求可用于告诉该跟踪继续进行下去：

• PTRACE_CONT ：这是最简单的。 跟踪将一直运行，直到接收到信号为止，这时将等待事件传递到跟踪器。 这最常用于实现实际调试器的“ continue-until-breakpoint”和“ continue-forever”选项。 断点将在下面介绍。
• PTRACE_SYSCALL ：非常相似PTRACE_CONT ，而是进入了一个系统调用之前停止，之前也一个系统调用返回到用户空间。 它可以与其他请求（我们将在本文后面介绍）结合使用，以监视和修改系统调用的参数或返回值。 strace （系统调用跟踪程序）大量使用此请求来确定进程进行了哪些系统调用。
• PTRACE_SINGLESTEP ：这是不言自明的。 如果您之前使用过调试器，则此请求将执行下一条指令，但之后立即停止。

我们可以通过各种请求来停止该过程，但是如何获取示踪的状态呢？ 进程的状态主要由其寄存器捕获，因此ptrace当然有一个获取（或修改！）寄存器的请求：

• PTRACE_GETREGS ：该请求将给出停止跟踪时的寄存器状态。
• PTRACE_SETREGS ：如果跟踪器具有上一次调用PTRACE_GETREGS的寄存器值，则可以通过该请求修改该结构中的值，并将寄存器设置为新值。
• PTRACE_PEEKUSER和PTRACE_POKEUSER ：这些允许从跟踪的USER区域读取，该区域保存寄存器和其他有用信息。 这可用于修改单个寄存器，而无需更重的PTRACE_{GET,SET}REGS 。

在调试器中修改寄存器并不总是足够的。 调试器有时需要读取存储器的某些部分，甚至对其进行修改。 GNU项目调试器（GDB）可以使用print获取内存位置或变量的值。 ptrace具有实现此功能的功能：

• PTRACE_PEEKTEXT和PTRACE_POKETEXT ：这些允许在跟踪的地址空间中读取和写入单词。 当然，必须停止示踪才能起作用。

现实世界中的调试器还具有断点和观察点之类的功能。 在下一节中，我将深入介绍调试支持的体系结构细节。 为了清楚和简洁起见，本文仅考虑x86。

建筑支持

ptrace很酷，但是它如何工作？ 在上一节中，我们已经看到了ptrace有相当多的做信号： SIGTRAP可以单步执行前交付， execve和之前或之后的系统调用。 信号可以通过多种方式生成，但是我们将看看两个特定的示例，调试器可以使用这些示例在给定位置停止程序（有效地创建断点！）：

• 未定义的指令：当进程尝试执行未定义的指令时，CPU会引发异常。 通过CPU中断处理此异常，然后调用与内核中的中断对应的处理程序。 这将导致SIGILL发送到该进程。 反过来，这导致进程停止，并通过等待事件通知跟踪程序。 然后，它可以决定要做什么。 在x86上，保证ud2指令ud2是未定义的。

• 调试中断：前一种方法的问题是ud2指令占用了两个字节的机器代码。 存在一条占用一个字节并引发中断的特殊指令。 它是int $3 ，机器代码是0xCC 。 引发此中断时，内核将SIGTRAP发送到进程，并且像以前一样，通知跟踪器。

很好，但是我们如何强迫示踪执行这些指令？ 容易： ptrace具有PTRACE_POKETEXT ，可以覆盖存储位置的单词。 调试器将使用PTRACE_PEEKTEXT读取该位置处的原始单词，并将其替换为0xCC ，从而记住原始字节以及该字节处于其内部状态的断点这一事实。 下次在该位置执行跟踪时，将借助SIGTRAP自动将其停止。 然后，调试器的最终用户可以决定如何继续（例如，检查寄存器）。

好的，我们已经介绍了断点，但是观察点呢？ 当读取或写入某个内存位置时，调试器如何停止程序？ 当然，您不会仅仅用int $3覆盖可以读取或写入某些内存位置的每条指令。 满足调试寄存器，一组旨在更有效地实现此目标的寄存器：

• DR0至DR3 ：每个寄存器都包含一个地址（存储位置），调试器出于某种原因希望该跟踪停止。 原因在DR7指定为位掩码。
• DR4和DR5 ：分别是DR6和DR7别名。
• DR6 ：调试状态。 包含有关哪个DR0到DR3引发调试异常的信息。 Linux使用它来确定与SIGTRAP一起传递给跟踪的信息。
• DR7 ：调试控件。 使用这些寄存器中的位，调试器可以控制如何解释DR0 至 DR3中指定的地址。 位掩码控制观察点的大小（监视的是1、2、4还是8个字节），以及是否在执行，读取，写入或读取和写入时引发异常。

因为调试寄存器构成了进程USER区域的一部分，所以调试器可以使用PTRACE_POKEUSER将值写入调试寄存器。 调试寄存器仅与特定进程相关，因此在进程重新获得对CPU的控制之前，它们会抢占先恢复为该值。

冰山一角

我们看了一眼调试器的冰山一角：我们介绍了ptrace ，介绍了它的一些功能，然后看了如何实现ptrace 。 ptrace某些部分可以用软件实现，而其他部分则必须用硬件实现，否则它们将非常昂贵，甚至不可能。

当然，我们没有涉及很多。 出现诸如“调试器如何知道变量在内存中的位置？”之类的问题。 由于时间和空间的限制，请保持开放状态，但我希望您从本文中学到了一些知识； 如果它激起了您的兴趣，可以在网上找到大量资源以了解更多信息。

---

有关更多信息，请参加Levente Kurusa的演讲， 让我们编写调试器！ ， 网址为linux.conf.au ，将于1月22日至26日在悉尼举行。

翻译自: https://opensource.com/article/18/1/how-debuggers-really-work

调试器原理