3. 多核调试架构解析

在单核调试中，主机调试器通过一条 JTAG 或 SWD 链路直接控制一个 CPU 核，断点、单步、内存访问都围绕这一个执行单元展开。进入多核场景后，问题立刻复杂化：一个 SoC 里可能同时存在 Cortex-A 应用核、Cortex-R 实时核、Cortex-M 控制核以及 DSP，它们各自有独立的寄存器组、MMU/MPU 配置和时钟域，却共享总线、内存与外设。Green Hills MULTI 的多核调试架构，本质上就是解决“一个主机调试界面如何同时、有序、可区分地控制多个异构核”的问题。理解这套架构，需要抓住四个关键角色：调试服务器（Debug Server）、目标代理（Target Agent）、核间通信通道，以及多核会话管理。

一、调试服务器：主机侧的多核调度中枢

MULTI 的调试服务器运行在主机（Windows 或 Linux 工作站）上，是调试器前端与目标硬件之间的中间层。它并不直接驱动 JTAG 引脚，而是负责：管理到目标探针的连接、维护每个核的调试上下文、把来自 MULTI IDE 的请求（如“在 core2 的 0x8000_1000 处设断点”）翻译成目标代理能识别的命令，并把目标返回的状态分发回正确的核视图。

在多核场景下，调试服务器最重要的能力是会话隔离。每个被调试的核在服务器内部对应一个独立的调试会话（Debug Session），拥有自己的断点表、寄存器缓存、内存映射视图和运行状态。当你在 MULTI 中打开四个核的调试窗口时，服务器实际维护着四套上下文，但共享同一条物理探针链路。这种“逻辑多路复用、物理单链路”的设计，是理解后续所有行为的基础。

二、目标代理：运行在目标侧的执行代理

目标代理是驻留在目标系统上的小型软件组件，通常由 MULTI 在连接时自动下载到目标内存中运行。它接收调试服务器下发的命令，直接操作目标硬件：读写内核寄存器、设置硬件断点、访问内存、控制核的暂停与恢复。对于异构多核，目标代理往往需要针对不同核架构提供对应的代理实例，例如 A 核使用一种代理，M 核使用另一种，但它们对上层呈现统一的命令接口。

目标代理与调试服务器之间的通信，通常走探针的物理通道（JTAG/SWD/ETM 等）。这里有一个关键约束：物理链路是串行的。即使四个核同时请求调试服务，命令也只能排队通过同一条链路。因此调试服务器必须做仲裁和优先级管理，否则会出现某个核的长时间内存读取阻塞其他核的断点响应。

三、核间通信通道：多核协同的“神经系统”

多核调试中，核与核之间并非完全独立。一个核可能需要知道另一个核是否已到达某个同步点，或者需要读取另一个核的共享内存数据。MULTI 通过核间通信通道（Inter-Core Communication Channel）来支持这类协同。这条通道不是物理总线，而是调试服务器内部建立的一条逻辑通路，允许一个核的调试会话向另一个核的调试会话发送通知、查询状态或触发同步动作。

典型应用场景是多核同步断点：当 core0 执行到函数 start_measure() 时，希望 core1 和 core2 也同时暂停，以便观察三核在同一时刻的寄存器状态。实现方式是：core0 的断点命中后，目标代理上报事件，调试服务器通过核间通信通道向 core1、core2 的会话发送“暂停”命令，三个核在毫秒级窗口内先后停止。虽然严格意义上不是同一时钟周期暂停，但对于大多数协同调试已经足够。

四、多核会话管理：谁在运行、谁在暂停

多核会话管理解决的是“状态一致性”问题。每个核可以处于运行（Running）、暂停（Halted）、复位（Reset）或未知（Unknown）状态。MULTI 的会话管理器维护一张全局状态表，并在用户执行“全部暂停”“全部恢复”“单核恢复”等操作时，按依赖关系依次下发命令。例如，若 core1 正在等待 core0 释放自旋锁，单独恢复 core1 会导致它空转，因此会话管理器允许你设置“同步恢复组”，让相关核一起恢复。

下面这张图展示了 MULTI 多核调试架构中四个核心角色的位置与数据流向。主机侧调试服务器通过物理探针链路连接目标侧目标代理，目标代理分别管理多个核；核间通信通道在调试服务器内部连接各核会话，多核会话管理则统一维护所有核的状态。

五、一次多核同步断点的完整路径

把上述四个角色串起来，可以看清一次典型多核调试操作的实际路径。假设你在 MULTI 中给 core0 的 0x8000_1000 地址设置硬件断点，并勾选“同步暂停 core1、core2”。操作序列如下：

1. MULTI IDE 把断点请求发给调试服务器，服务器在 core0 会话中登记断点，并通过物理链路把断点地址下发给目标代理。
2. 目标代理在 core0 的调试寄存器中写入断点地址，返回确认。
3. core0 运行到该地址，硬件断点触发，core0 暂停，目标代理捕获事件并上报调试服务器。
4. 调试服务器识别到该断点关联了同步组，通过核间通信通道向 core1、core2 会话发送暂停命令。
5. core1、core2 的目标代理分别执行暂停，返回各自的状态（PC、寄存器、暂停原因）。
6. 多核会话管理器更新全局状态表，MULTI IDE 同时刷新三个核的调试视图。

整个过程的关键判断依据是：三个核的暂停原因是否都显示为“同步断点触发”，以及暂停时间差是否在可接受范围内。如果某个核显示“超时未响应”，通常意味着该核正处于低功耗模式、时钟被关闭，或者目标代理在该核上未正确初始化。

六、配置多核会话时的实际参数

在 MULTI 中建立多核调试连接时，需要关注几个实际参数。以常见的四核 SoC 为例，连接配置通常包含：

这些参数没有“万能值”，需要根据目标板实际布线、核间耦合程度和调试目标来调整。例如，当 Core0 运行 Linux 且已启用 MMU 时，调试服务器需要加载对应的地址转换表，否则你看到的虚拟地址与物理地址会不一致；而 Core2 作为裸机控制核，通常直接使用物理地址即可。

七、核间通信通道的边界与限制

核间通信通道虽然强大，但并非没有边界。它依赖调试服务器和目标代理的正常工作，因此当某个核完全失去响应（例如进入深度睡眠且调试时钟关闭）时，通道无法唤醒它。此外，核间通信的延迟通常在毫秒级，不适合用于需要微秒级同步的实时场景。对于这类需求，更合适的方式是在应用代码中使用硬件信号量或共享内存标志位，调试器只负责观察，而不是参与同步。

理解这些边界，有助于在实际调试中合理选择手段：调试器负责“看”和“控”，应用代码负责“同步”和“通信”，两者分工明确，才能既保证调试效率，又不干扰目标系统的真实行为。