debugger(四):源代码

2024-06-11 05:44
文章标签 源代码 debugger

本文主要是介绍debugger(四):源代码,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

〇、前言

终于来到令人激动的源代码 level 了,这里将会有一些很有意思的算法,来实现源代码级别的调试,这将会非常有趣。

一、使用 libelfin 库

我们不可能直接去读取整个 .debug info 段来进行设置,这是没有必要的,可以使用现成的库。首先初始化 debugger 对象:

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;
};

不必太过关注这里函数的细节,只需要关注它们做了什么。事实上,m_dwarf、m_elf 和 文件名 m_prog_name 关联起来了,然后就交给它们进行处理了。我们还需要知道 load_addr,这非常重要,因为debuf info 只会提供静态的信息,load_addr 取决于运行时,因此得想办法在 /proc 中获取:

void Debugger::initialise_load_address() {if (m_elf.get_hdr().type == elf::et::dyn) {std::ifstream map("/proc/" + std::to_string(m_pid) + "/maps");//Read the first address from the filestd::string addr;std::getline(map, addr, '-');m_load_address = std::stoi(addr, 0, 16);}
}

二、获取信息

通过一个 pc 怎么获取函数名呢?注意这个 pc 是一个 offset addr,传参的时候一定要转换。思路很简单,首先遍历所有的 cu,然后判断 culow_pchigh_pc,如果在这个 cu 符合,那么就通过 cu 拿到 cu.rootcu.root 是一个根 die,通过它可以遍历所有的 die。之后再判断 dietag 是不是一个函数,如果是且包含 pc,那么就是我们要找的函数。实现如下:

dwarf::die Debugger::get_function_from_pc(std::intptr_t pc) {for (auto &cu : m_dwarf.compilation_units()) { // 循环遍历所有cuif (die_pc_range(cu.root()).contains(pc)) {for (const auto &die :cu.root()) { if (die.tag ==dwarf::DW_TAG::subprogram) { if (die_pc_range(die).contains(pc)) {return die;}}}}}throw std::out_of_range{"Cannot find function"};
}

接着通过 pc 来获取 line entry:

dwarf::line_table::iterator Debugger::get_line_entry_from_pc(uint64_t pc) {for (auto &cu : m_dwarf.compilation_units()) {if (die_pc_range(cu.root()).contains(pc)) {auto &lt = cu.get_line_table();auto it = lt.find_address(pc);if (it == lt.end()) {throw std::out_of_range{"Cannot find line entry"};}else {return it;}}}throw std::out_of_range{"Cannot find line entry"};
}

接着我们打印源代码。思路是通过 debug info 中的源代码路径和 line table 来获取,好消息是,我们不必做更多的底层实现:

void Debugger::print_source(const std::string& file_name, unsigned line, unsigned n_lines_context) {std::ifstream file {file_name};auto start_line = line <= n_lines_context ? 1 : line - n_lines_context;auto end_line = line + n_lines_context + (line < n_lines_context ? n_lines_context - line : 0) + 1;char c{};auto current_line = 1u;while (current_line != start_line && file.get(c)) {if (c == '\n') {++current_line;}}std::cout << (current_line==line ? "> " : "  ");while (current_line <= end_line && file.get(c)) {std::cout << c;if (c == '\n') {++current_line;std::cout << (current_line==line ? "> " : "  ");}}std::cout << std::endl;
}

三、测试

minidbg> break 0x555555555191
Set breakpoint at address 0x555555555191
minidbg> conti
Hit breakpoint at adsress 0x555555555191#include <iostream>int main() {
>   std::cerr << "hello,world0.\n";return 0;}

我们确实成功的打印出了源代码。上述基本的信息获取,基本思路就是对 DWARF 的理解,然后利用库函数接口获取我们想要的信息。

这篇关于debugger(四):源代码的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1050340

相关文章

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

Debugging Lua Project created in Cocos Code IDE creates “Waiting for debugger to connect” in Win-7

转自 I Installed Cocos Code IDE and created a new Lua Project. When Debugging the Project(F11) the game window pops up and gives me the message waiting for debugger to connect and then freezes. Also a

运营版开源代码 多语言跨境商城 跨境电商平台

默认中英双语 后台带翻译接口 支持133种语言自动翻译 支持多商户联盟 一键部署版本 伪静态+后台登陆后缀 源码下载:https://download.csdn.net/download/m0_66047725/89722389 更多资源下载:关注我。

容器第四课,JDK源代码分析,自己实现LinkedList,双向链表的概念_节点定义

package com.pkushutong.Collection;public class Test03 {private Test03_01 first; //第一个节点private Test03_01 last; //最后一个节点private int size;public void add(Object obj){Test03_01 t = new Test03_01();if(fi

【UE4源代码观察】观察Core模块

话题 Core模块是整个引擎中最核心的模块,在之前的博客【UE4源代码观察】可视化所有模块的依赖情况中有统计,它被983个模块引用,恐怕除了第三方的模块外基本所有模块都有引用。我想首先观察其中的内容,然后再做测试:将Core模块拷贝到之前【UE4源代码观察】手动建立一个使用UBT进行编译的空白工程建立的空白工程中,看能否将它成功编译,理论上讲,“核心”不应再依赖太多其他的东西,所以我应该不会再需

【UE4源代码观察】在空白工程中测试跨模块调用函数

目的 在之前的博客【UE4源代码观察】手动建立一个使用UBT进行编译的空白工程中,成功让UBT工作起来了。现在我想要测试编译出的多个模块之间是否能互相调用,我记录下测试的过程。最终工程见 工程GIT链接。 实践 第一部分 首先仿照TestA模块建立TestB模块。 在TestB.h文件中声明了一个函数 int TestBFunc(int x, int y); 并在TestB.cpp中

【UE4源代码观察】观察FEngineLoop中各函数的调用顺序

当启动编辑器时,Launch模块是启动模块,在Windows平台中 LaunchWindows.cpp 的 WinMain函数是入口,而 FEngineLoop 管理了程序的初始化与主循环。他的成员函数如下: public:/*** Pre-Initialize the main loop, and generates the commandline from standard ArgC/Arg

【UE4源代码观察】手动建立一个使用UBT进行编译的空白工程

我想观察UE4是怎么编译的,于是查阅官方文档,了解到UE4有一套自己的编译工具:UnrealBuildTool,简称UBT。关于UBT的官方文档参阅:虚幻编译工具。我想尝试自己手动建立一个使用UBT进行编译的空白工程。不过首先,先了解下UBT的编译流程中一些文件所扮演的角色 UBT的编译流程中一些文件所扮演的角色 模块 每个模块都由一个 .build.cs 文件声明,它存储在 Source

【UE4源代码观察】可视化所有模块的依赖情况

思路 UE4引擎的模块非常多,我想要观察他们的依赖情况。于是我写了程序读取所有模块的.Build.cs文件,记录每个模块依赖的模块(当前是看PublicDependencyModuleNames和PrivateDependencyModuleNames。但后来经评论提醒我发现AddEngineThirdPartyPrivateStaticDependencies也应该视作是“依赖”但没统计,后续

【UE4源代码观察】观察TargetPlatform模块

前情提要与本次目标 在之前的博客《【UE4源代码观察】观察 RHI、D3D11RHI、RenderCore 这三个模块的依赖关系》中,我将RHI、D3D11RHI、RenderCore这三个模块加入了我的空白工程中并确保可以成功编译。然而当时RenderCore模块有一个比较大的缺失:没有让shader相关的功能正常编译,因为它需要TargetPlatform模块中的内容。 因此,这次我想观察