在上一部分中，我们了解了DWARF格式的信息以及如何使用它来读取变量，并将高级语言的源代码与正在执行的机器码关联起来。在这一部分中，我们将通过在调试器中使用DWARF原型。我们还将利用这个机会让我们的调试器在遇到断点时打印当前源上下文。

还记得在本系列的开始我提到了的libelfin吗，我们将在本节使用libelfin来处理我们的DWARF信息。 你可以去看下第一篇，但如果不想去或是记不得了，请现在这样做，下载libelfin库并确保你使用我修改过的fbreg分支(github上的代码)。

一旦你编译好了libelfin，就可以立即添加到我们的调试器里。第一步先解析我们给出的ELF可执行文件，并从中提取DWARF格式信息。这对libelfin来说非常简单，只需对调试器进行这些更改即可：

使用open来代替std::ifstream,因为ELF加载器需要一个Unix文件描述符来传递给mmap，以便它可以将文件映射到内存中，而不是一次读取它。

接下来，我们可以实现一些函数，从PC值获取行条目和函数DIE。 我们从get_function_from_pc开始：

在这里，我采取一种简单的方式，只需迭代编译单元，直到找到包含程序计数器的代码，然后遍历子函数，直到找到相关函数（DW_TAG_subprogram）。 如上一篇文章所述，您可以处理像成员函数这样的内容，如果需要，可以在这里进行内联。

下一个是get_line_entry_from_pc:

再次，我们只是找到正确的编译单元，然后从debugline表来获取相关条目。

当我们点击一个断点或者绕过我们的代码时，我们会想知道我们最终的来源,我们可以打印源码。

现在我们可以打印出来源码，我们需要把它挂接到我们的调试器中。 一个好的做法是调试器从断点或（最终）单步获取信号。 在我们这样做的时候，我们可能会想要为我们的调试器添加更好的信号处理。

我们想知道什么信号被发送到进程，但是我们也想知道它是如何生成的。 例如，我们想要能够告诉我们是否有一个SIGTRAP，因为我们打破了一个断点，或者是因为一个步骤完成，或者一个新的线程产生等等。幸运的是，ptrace再次来到我们的救援。 ptrace可能的命令之一是PTRACE_GETSIGINFO，它将为您提供有关进程发送的最后一个信号的信息。 我们这样使用它：

这给我们一个siginfo_t对象，它提供以下信息：

我只需要使用si_signo来计算出哪个信号被发送，并且si_code来获取关于信号的更多信息。 放这个代码的最好的地方在我们的wait_for_signal函数中：

现在来处理SIGTRAP。 只要有一个断点被触发，就会发送SI_KERNEL或TRAP_BRKPT，TRAP_TRACE将在单步完成时发送：

有一堆不同的信号和风格的信号，你可以处理。 有关更多信息，请参阅man sigaction。

由于我们现在在获取SIGTRAP时更正程序计数器，因此我们可以从step_over_breakpoint中删除已编码的代码，现在看起来像：

现在你应该能够在某个地址设置一个断点，运行该程序并查看使用当前执行的标有光标的行打印的源代码。

下次我们将添加设置源码级断点的功能。 在此期间，您可以在此处获取此帖的代码。

原文： https://blog.tartanllama.xyz/writing-a-linux-debugger-source-signal/
译文作者： lantie@15PB 15PB信息安全教育 http://www.15pb.com.cn

添加下载的libelfin目录到Clion项目中配置CMakeLists.txt中

使用调试器调试程序hello15pb，打印源码

使用Clion编译的完整工程

class debugger {
public:
    debugger (std::string prog_name, pid_t pid)
         : m_prog_name{std::move(prog_name)}, m_pid{pid} {
        auto fd = open(m_prog_name.c_str(), O_RDONLY);

        m_elf = elf::elf{elf::create_mmap_loader(fd)};
        m_dwarf = dwarf::dwarf{dwarf::elf::create_loader(m_elf)};
    }
    //...

private:
    //...
    dwarf::dwarf m_dwarf;
    elf::elf m_elf;
};

[注意]APP应用上架合规检测服务，协助应用顺利上架！