mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
PUB:20170331 Writing a Linux Debugger Part 3 Registers and memory.md
@ictlyh @jasminepeng
This commit is contained in:
wxy
parent
32ae9ead8b
commit
cb570f2b8c
@ -1,39 +1,26 @@
|
||||
开发 Linux 调试器（三）：寄存器和内存
|
||||
开发一个 Linux 调试器（三）：寄存器和内存
|
||||
============================================================
|
||||
|
||||
上一篇博文中我们给调试器添加了一个简单的地址断点。这次，我们将添加读写寄存器和内存的功能，这将使我们能够使用我们的程序计数器、观察状态和改变程序的行为。
|
||||
|
||||
* * *
|
||||
|
||||
### 系列文章索引
|
||||
|
||||
随着后面文章的发布，这些链接会逐渐生效。
|
||||
|
||||
1. [准备环境][3]
|
||||
|
||||
1. [准备环境][3]
|
||||
2. [断点][4]
|
||||
|
||||
3. [寄存器和内存][5]
|
||||
|
||||
4. [Elves 和 dwarves][6]
|
||||
|
||||
5. [源码和信号][7]
|
||||
|
||||
6. [源码级逐步执行][8]
|
||||
|
||||
7. 源码级断点
|
||||
|
||||
8. 调用栈展开
|
||||
|
||||
9. 读取变量
|
||||
|
||||
10. 下一步
|
||||
|
||||
* * *
|
||||
|
||||
### 注册我们的寄存器
|
||||
|
||||
在我们真正读取任何寄存器之前，我们需要告诉调试器一些关于我们的目标，也就是 x86_64 的信息。除了多组通用和专用目的寄存器，x86_64 还提供浮点和向量寄存器。为了简化，我将跳过后两种寄存器，但是你如果喜欢的话也可以选择支持它们。x86_64 也允许你像访问 32、16 或者 8 位寄存器那样访问一些 64 位寄存器，但我只会介绍 64 位寄存器。由于这些简化，对于每个寄存器我们只需要它的名称，它的 DWARF 寄存器编号以及 `ptrace` 返回结构体中的存储地址。我使用范围枚举引用这些寄存器，然后我列出了一个全局寄存器描述符数组，其中元素顺序和 `ptrace` 中寄存器结构体相同。
|
||||
在我们真正读取任何寄存器之前，我们需要告诉调试器一些关于我们的目标平台的信息，这里是 x86_64 平台。除了多组通用和专用目的寄存器，x86_64 还提供浮点和向量寄存器。为了简化，我将跳过后两种寄存器，但是你如果喜欢的话也可以选择支持它们。x86_64 也允许你像访问 32、16 或者 8 位寄存器那样访问一些 64 位寄存器，但我只会介绍 64 位寄存器。由于这些简化，对于每个寄存器我们只需要它的名称、它的 DWARF 寄存器编号以及 `ptrace` 返回结构体中的存储地址。我使用范围枚举引用这些寄存器，然后我列出了一个全局寄存器描述符数组，其中元素顺序和 `ptrace` 中寄存器结构体相同。
|
||||
|
||||
```
|
||||
enum class reg {
|
||||
@ -88,7 +75,7 @@ const std::array<reg_descriptor, n_registers> g_register_descriptors {{
|
||||
|
||||
如果你想自己看看的话，你通常可以在 `/usr/include/sys/user.h` 找到寄存器数据结构，另外 DWARF 寄存器编号取自 [System V x86_64 ABI][11]。
|
||||
|
||||
现在我们可以编写一堆函数来和寄存器交互。我们想要读取寄存器、写入数据、根据 DWARF 寄存器编号获取值，以及通过名称查找寄存器，反之类似。让我们先从实现 `get_register_value` 开始：
|
||||
现在我们可以编写一堆函数来和寄存器交互。我们希望可以读取寄存器、写入数据、根据 DWARF 寄存器编号获取值，以及通过名称查找寄存器，反之类似。让我们先从实现 `get_register_value` 开始：
|
||||
|
||||
```
|
||||
uint64_t get_register_value(pid_t pid, reg r) {
|
||||
@ -100,7 +87,7 @@ uint64_t get_register_value(pid_t pid, reg r) {
|
||||
|
||||
`ptrace` 使得我们可以轻易获得我们想要的数据。我们只需要构造一个 `user_regs_struct` 实例并把它和 `PTRACE_GETREGS` 请求传递给 `ptrace`。
|
||||
|
||||
现在取决于被请求的寄存器，我们想要读取 `regs`。我们可以写一个很大的 switch 语句，但由于我们 `g_register_descriptors` 表的布局顺序和 `user_regs_struct` 相同，我们只需要搜索寄存器描述符的索引，然后作为 `uint64_t` 数组访问 `user_regs_struct`。[1][9]
|
||||
现在根据要请求的寄存器，我们要读取 `regs`。我们可以写一个很大的 switch 语句，但由于我们 `g_register_descriptors` 表的布局顺序和 `user_regs_struct` 相同，我们只需要搜索寄存器描述符的索引，然后作为 `uint64_t` 数组访问 `user_regs_struct` 就行。（你也可以重新排序 `reg` 枚举变量，然后使用索引把它们转换为底层类型，但第一次我就使用这种方式编写，它能正常工作，我也就懒得改它了。）
|
||||
|
||||
```
|
||||
auto it = std::find_if(begin(g_register_descriptors), end(g_register_descriptors),
|
||||
@ -109,9 +96,9 @@ uint64_t get_register_value(pid_t pid, reg r) {
|
||||
return *(reinterpret_cast<uint64_t*>(®s) + (it - begin(g_register_descriptors)));
|
||||
```
|
||||
|
||||
到 `uint64_t` 的转换是安全的，因为 `user_regs_struct` 是一个标准布局类型，但我认为指针算术技术上是未定义的行为（undefined behavior）。当前没有编译器会对此产生警告，我也懒得修改，但是如果你想保持最严格的正确性，那就写一个大的 switch 语句。
|
||||
到 `uint64_t` 的转换是安全的，因为 `user_regs_struct` 是一个标准布局类型，但我认为指针算术技术上是<ruby>未定义的行为<rt>undefined behavior</rt></ruby>。当前没有编译器会对此产生警告，我也懒得修改，但是如果你想保持最严格的正确性，那就写一个大的 switch 语句。
|
||||
|
||||
`set_register_value` 非常类似，我们只是写入到地址并在最后写回寄存器：
|
||||
`set_register_value` 非常类似，我们只是写入该位置并在最后写回寄存器：
|
||||
|
||||
```
|
||||
void set_register_value(pid_t pid, reg r, uint64_t value) {
|
||||
@ -166,12 +153,10 @@ void debugger::dump_registers() {
|
||||
}
|
||||
```
|
||||
|
||||
正如你看到的，iostreams 有非常精确的接口用于美观地输出十六进制数据[2][10]。如果你喜欢你也可以通过 I/O 操纵器来摆脱这种混乱。
|
||||
正如你看到的，iostreams 有非常精确的接口用于美观地输出十六进制数据（啊哈哈哈哈哈哈）。如果你喜欢你也可以通过 I/O 操纵器来摆脱这种混乱。
|
||||
|
||||
这些已经足够支持我们在调试器接下来的部分轻松地处理寄存器，所以我们现在可以把这些添加到我们的用户界面。
|
||||
|
||||
* * *
|
||||
|
||||
### 显示我们的寄存器
|
||||
|
||||
这里我们要做的就是给 `handle_command` 函数添加一个命令。通过下面的代码，用户可以输入 `register read rax`、 `register write rax 0x42` 以及类似的语句。
|
||||
@ -191,7 +176,6 @@ void debugger::dump_registers() {
|
||||
}
|
||||
```
|
||||
|
||||
* * *
|
||||
|
||||
### 接下来做什么？
|
||||
|
||||
@ -225,13 +209,11 @@ void debugger::write_memory(uint64_t address, uint64_t value) {
|
||||
}
|
||||
```
|
||||
|
||||
* * *
|
||||
|
||||
### 给 `continue_execution` 打补丁
|
||||
|
||||
在我们测试我们的更改之前，我们现在可以实现一个更健全的 `continue_execution` 版本。由于我们可以获取程序计数器，我们可以检查我们的断点映射来判断我们是否处于一个断点。如果是的话，我们可以停用断点并在继续之前跳过它。
|
||||
|
||||
为了清晰和简洁，首先我们要添加一些帮助函数：
|
||||
为了清晰和简洁起见，首先我们要添加一些帮助函数：
|
||||
|
||||
```
|
||||
uint64_t debugger::get_pc() {
|
||||
@ -288,11 +270,9 @@ void debugger::continue_execution() {
|
||||
}
|
||||
```
|
||||
|
||||
* * *
|
||||
|
||||
### 测试效果
|
||||
|
||||
现在我们可以读取和修改寄存器了，我们可以对我们的 hello world 程序做一些有意思的更改。类似第一次测试，再次尝试在 call 指令处设置断点然后从那里继续执行。你可以看到输出了 `Hello world`。现在是有趣的部分，在输出调用后设一个断点、继续、将 call 参数设置代码的地址写入程序计数器(`rip`) 并继续。由于程序计数器操纵，你应该再次看到输出了 `Hello world`。为了以防你不确定在哪里设置断点，下面是我上一篇博文中的 `objdump` 输出：
|
||||
现在我们可以读取和修改寄存器了，我们可以对我们的 hello world 程序做一些有意思的更改。类似第一次测试，再次尝试在 `call` 指令处设置断点然后从那里继续执行。你可以看到输出了 `Hello world`。现在是有趣的部分，在输出调用后设一个断点、继续、将 `call` 参数设置代码的地址写入程序计数器（`rip`）并继续。由于程序计数器操纵，你应该再次看到输出了 `Hello world`。为了以防你不确定在哪里设置断点，下面是我上一篇博文中的 `objdump` 输出：
|
||||
|
||||
|
||||
```
|
||||
@ -313,18 +293,12 @@ void debugger::continue_execution() {
|
||||
在下一篇博客中，我们会第一次接触到 DWARF 信息并给我们的调试器添加一系列逐步调试的功能。之后，我们会有一个功能工具，它能逐步执行代码、在想要的地方设置断点、修改数据以及其它。一如以往，如果你有任何问题请留下你的评论！
|
||||
|
||||
你可以在[这里][13]找到这篇博文的代码。
|
||||
|
||||
* * *
|
||||
|
||||
1. 你也可以重新排序 `reg` 枚举变量，然后使用索引把它们转换为底层类型，但第一次我就使用这种方式编写，它能正常工作，我也就懒得改它了。 [↩][1]
|
||||
|
||||
2. Ahahahahahahahahahahahahahahahaha [↩][2]
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://blog.tartanllama.xyz/c++/2017/03/31/writing-a-linux-debugger-registers/
|
||||
|
||||
作者：[ TartanLlama ][a]
|
||||
作者：[Simon Brand][a]
|
||||
译者：[ictlyh](https://github.com/ictlyh)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user