3、avatar2核心概念：QEMU系统仿真模式、avatar2的架构（target、protocol、connection）、编写第一个avatar2脚本控制仿真器

好，咱们正式开始动手了。

这一章，我会带你搞清楚avatar2最核心的几个概念。说白了，就是弄明白avatar2到底怎么跟仿真器“对话”的。我个人觉得，这部分是入门avatar2最关键的一步。你想想看，如果连工具怎么跟目标通信都不清楚，后面那些花哨的调试技巧根本用不上。

3.1 QEMU系统仿真模式——为什么选它？

先聊聊QEMU。很多朋友问我：“老师，为什么非要用QEMU？我用Unicorn不行吗？”

嗯，这个问题问得好。Unicorn确实轻量，但它的短板也很明显——它只仿真CPU指令，没有外设、没有内存映射、没有中断控制器。你想想看，一个固件跑起来，它要读写寄存器、要处理中断、要跟硬件交互。Unicorn在这块儿基本帮不上忙。

我在项目中遇到过好几次，用Unicorn跑一个RTOS的固件，结果卡在某个外设寄存器读取上，直接崩了。后来换成QEMU系统仿真模式，一切就顺了。

核心区别：
  • QEMU用户态模式（User Mode）：只仿真单个进程，适合跑Linux应用程序。固件调试基本用不上。
  • QEMU系统仿真模式（System Mode）：仿真整个硬件平台，包括CPU、内存、外设、中断控制器。固件可以“以为”自己在真实硬件上跑。

avatar2主要依赖的就是QEMU系统仿真模式。它启动一个完整的虚拟机，然后avatar2通过某种协议“插”进去，控制它的执行流、读写内存、设置断点。这就是整个调试链条的基础。

我的建议：如果你刚开始接触，别纠结于自己编译QEMU。直接用avatar2自带的QEMU包，或者用官方预编译的版本。省时间，少踩坑。

3.2 avatar2的架构——Target、Protocol、Connection

好，现在咱们看看avatar2的内部结构。我把它拆成三个词：Target、Protocol、Connection。你记住这三个，avatar2的架构就懂了八成。

3.2.1 Target——你要调试的目标

Target就是你要调试的那个东西。它可以是QEMU虚拟机，也可以是真实的硬件调试器（比如JTAG连着的开发板），甚至可以是GDB Server。avatar2把所有这些都抽象成Target对象。

每个Target都有自己的属性：架构（ARM、MIPS、RISC-V）、内存布局、寄存器集合。你创建Target的时候，就是在告诉avatar2：“我要跟这个家伙打交道。”

3.2.2 Protocol——怎么跟Target说话

Protocol是通信协议。avatar2支持好几种：

  • QMP（QEMU Machine Protocol）：跟QEMU通信的主要协议。通过QMP，avatar2可以发送命令给QEMU，比如“暂停执行”、“读取内存”、“设置断点”。
  • GDB Protocol：通过GDB远程调试协议跟Target通信。如果你用真实的JTAG调试器，或者QEMU开启了GDB stub，就用这个。
  • Avatar Protocol：avatar2自己定义的协议，用于跟自定义的仿真器或硬件接口通信。

我个人习惯，调试固件时首选QMP。为什么？因为它比GDB协议更底层，控制粒度更细。GDB协议有时候会做一些“智能”处理，比如自动处理某些断点条件，反而碍事。

3.2.3 Connection——建立通信链路

Connection就是实际的通信链路。它负责建立和维护avatar2与Target之间的连接。比如，对于QEMU Target，Connection会启动QEMU进程，然后通过QMP协议跟它握手。连接建立后，avatar2才能发送命令、接收响应。

一句话总结：Target是“谁”，Protocol是“怎么说”，Connection是“怎么连”。三者缺一不可。

为了让你更直观地理解，我画了一张图：

avatar2 主控 Connection Protocol (QMP/GDB) Target (QEMU) avatar2 架构分层 1. 主控：管理所有Target和调试会话 2. Connection：建立和维护通信链路 3. Protocol：定义通信协议（QMP/GDB等） 4. Target：实际调试目标（QEMU/硬件）

3.3 编写第一个avatar2脚本——控制仿真器

理论说完了，咱们直接上代码。我带你写一个最简单的avatar2脚本：启动QEMU，暂停它，读一下PC寄存器的值，然后退出。

注意：运行这个脚本前，确保你已经安装了avatar2和QEMU。如果还没装，去avatar2的GitHub仓库看README，跟着装就行。我曾经在这上面浪费过一下午——因为Python环境冲突，avatar2死活装不上。后来用虚拟环境（venv）才搞定。 
#!/usr/bin/env python3
# 第一个avatar2脚本：启动QEMU并读取PC寄存器

import avatar2
import time

# 1. 创建avatar2主控对象
avatar = avatar2.Avatar()

# 2. 配置QEMU Target
#    这里以ARM Cortex-M3为例，你可以换成你自己的固件
qemu_config = avatar2.QemuTarget(
    name="my_qemu",
    architecture=avatar2.Architecture.ARM,
    cpu_model="cortex-m3",
    qemu_path="/usr/bin/qemu-system-arm",  # 改成你的QEMU路径
    memory_mapping=[
        # 映射固件到0x08000000（STM32的Flash起始地址）
        avatar2.MemoryMapping(0x08000000, 0x00010000, "firmware.bin"),
        # 映射RAM到0x20000000
        avatar2.MemoryMapping(0x20000000, 0x00020000, None)
    ]
)

# 3. 添加Target到avatar
avatar.add_target(qemu_config)

# 4. 建立连接
#    这一步会启动QEMU进程，并通过QMP协议握手
avatar.init_targets()

# 5. 暂停仿真器
avatar.stop()

# 6. 读取PC寄存器
pc_value = avatar.read_register("pc")
print(f"PC寄存器当前值: 0x{pc_value:08x}")

# 7. 读取内存（可选）
#    比如读取固件入口点的前16个字节
entry_data = avatar.read_memory(0x08000000, 16)
print(f"入口点数据: {entry_data.hex()}")

# 8. 关闭连接
avatar.shutdown()

这个脚本虽然短，但包含了avatar2调试固件的完整流程：

  1. 创建Avatar对象：所有操作的入口。
  2. 配置Target：指定架构、CPU型号、内存映射。这里的内存映射很关键——你得告诉avatar2，固件放在哪个地址，RAM在哪个地址。我见过有人把固件映射到错误的地址，结果QEMU启动后直接跑飞。
  3. 添加Target并初始化：这一步会启动QEMU进程。如果QEMU路径不对，或者固件文件不存在，这里会报错。
  4. 暂停仿真器：刚启动的QEMU可能已经在跑了，先暂停下来，方便我们操作。
  5. 读写寄存器/内存：这就是我们调试的核心操作。你可以读PC、SP、LR，也可以读任意地址的内存。
  6. 关闭连接：调试结束，记得清理资源。
避坑指南：我曾经在读取寄存器时，忘了先暂停仿真器。结果avatar2返回了一个错误，说“Target is running”。所以记住：读写寄存器前，先stop()。另外，QEMU的CPU模型一定要选对。比如ARM Cortex-M系列，如果你选了cortex-a8，那很多M系列特有的寄存器（如xPSR）就访问不到。

3.4 进阶：让仿真器跑起来，再打断它

刚才的例子是启动后直接暂停。但实际调试中，我们往往想让固件先跑一会儿，然后在某个点停下来。比如，让固件执行到main函数入口。

怎么做？很简单：

# 启动后让QEMU跑一会儿
avatar.cont()  # 继续执行
time.sleep(0.5)  # 等500毫秒
avatar.stop()   # 暂停

# 现在读取PC，看看跑到哪了
pc_value = avatar.read_register("pc")
print(f"跑了500ms后，PC在: 0x{pc_value:08x}")

你可能会问：“这样靠谱吗？万一固件在500ms内跑完了怎么办？”

嗯，确实有这个问题。更稳妥的做法是设置断点。比如，你想在0x08000100处停下来：

# 设置断点
avatar.set_breakpoint(0x08000100)

# 让固件跑起来
avatar.cont()

# 等待断点命中
# avatar2会阻塞在这里，直到断点触发
avatar.wait_for_breakpoint()

# 断点命中后，读取寄存器
pc_value = avatar.read_register("pc")
print(f"断点命中，PC = 0x{pc_value:08x}")

这才是真正的调试。你想想看，有了断点，你就可以让固件跑到任意你想分析的位置，然后停下来慢慢看内存、看寄存器。后面章节我们会深入讲断点的各种玩法。

3.5 本章小结

这一章我们干了三件事：

  • 搞清楚了QEMU系统仿真模式为什么适合固件调试
  • 拆解了avatar2的三大核心概念：Target、Protocol、Connection
  • 写了一个完整的avatar2脚本，控制QEMU启动、暂停、读写寄存器

说实话，这些内容看起来简单，但它们是后面所有高级技巧的基础。我见过不少学员，上来就想搞复杂的多核调试、内存追踪，结果连最基本的Target配置都搞错，折腾半天出不来结果。

所以，我建议你亲手跑一遍上面的脚本。哪怕只是打印出PC寄存器的值，也算迈出了第一步。遇到问题别慌，先检查QEMU路径、固件路径、内存映射对不对。这三个地方出错的概率最高。

记住：avatar2的核心价值，就是让你用Python脚本，像操作GDB一样控制仿真器。但比GDB更灵活、更可编程。后面我们会一步步展示它的威力。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →