4. 多核断点与观察点实战

多核调试与单核调试最大的差别，不在于“能不能下断点”，而在于断点资源是全局稀缺的、触发事件是跨核可见的、共享内存访问是并发交错的。TRACE32 把断点（Breakpoint）和观察点（Watchpoint）统一纳入硬件断点资源池管理，理解资源如何分配、事件如何跨核传播、数据访问如何被监控，是排查多核死锁、竞态和内存踩踏的基础。

一、硬件断点资源的分配模型

每个 CPU 核内部通常只有 2～8 个硬件断点寄存器（如 ARM CoreSight 的 BRP/WRP、PowerPC 的 IABR/DABR）。TRACE32 通过 Break.List 查看当前占用情况，通过 Break.Set 申请资源。关键规则是：断点寄存器属于某个核，不能跨核共享。若在 core0 上设置 4 个断点而该核只有 4 个寄存器，第 5 个断点会失败并报 no more breakpoints available。

资源分配遵循“先到先得 + 类型匹配”原则：执行断点占用指令断点寄存器，数据观察点占用数据断点寄存器，二者通常不通用。因此规划断点时，应先统计各核需要监控的地址数量，再决定哪些用硬件断点、哪些改用软件断点（Break.Set /Soft，通过替换指令实现，不占硬件资源，但只能用于 RAM 中的代码）。

Break.List                     ; 查看所有核的断点占用
Break.Set 0x80001234 /Onchip  ; core0 硬件执行断点
Break.Set 0x80005678 /Onchip /ReadWrite /Data  ; 数据观察点
Break.Delete /All             ; 释放全部资源

二、跨核断点触发与同步

多核系统里，一个核命中断点后，其他核是否停止取决于调试模式。TRACE32 提供三种典型行为：

• Individual（独立）：仅命中核停止，其余核继续运行，适合观察单核行为；
• Group（组同步）：同一 SMP 组内所有核一起停止，适合分析核间交互；
• Go/Stop 联动：通过 SYStem.Mode 与 Break.Option 配置，命中后广播停止请求。

实际调试核间通信时，推荐使用 Group 模式。例如 core0 在向共享队列写入后命中断点，此时 core1 也被冻结，可以同时查看两核的 PC、寄存器和共享内存，判断 core1 是否已进入等待该队列的状态。若使用 Individual 模式，core1 可能在 core0 停止期间继续消费数据，导致现场被破坏。

三、数据观察点设置与共享内存监控

数据观察点用于监控“谁写了这个地址”。设置时需要明确三个要素：地址、访问类型（读/写/读写）、数据宽度。TRACE32 语法为：

Break.Set 0x90000000--0x900000FF /Write /Data /Onchip
Var.Watch %SpotLight 0x90000000 /Write

上例监控共享缓冲区 0x90000000～0x900000FF 的写操作。当任意核写入该区间时触发，TRACE32 会记录命中核、访问地址、写入值和 PC。若硬件支持地址掩码，可用范围监控；若不支持，则需拆分为多个单地址观察点，此时要特别注意资源消耗。

四、断点冲突与资源耗尽处理

常见冲突有三类：资源耗尽（寄存器不够）、地址重叠（同一地址被多次设置）、软硬断点混用冲突（软件断点修改了指令，硬件断点又指向同一位置）。处理策略如下：

1. 用 Break.List 找出占用最多的核，删除不再需要的断点；
2. 将只读监控改为 Var.Watch 或 Trace 采样，减少硬件断点占用；
3. 把非关键执行断点改为软件断点，释放指令断点寄存器；
4. 对共享内存监控，优先使用 ETM/ETB 等跟踪单元做数据流记录，而非全部依赖观察点。

五、实战判断流程

下面这张图给出从“设置断点”到“判断是否命中并定位问题”的完整信号链，涵盖资源分配、跨核触发、数据观察点命中和冲突处理四条路径，可作为多核断点调试的速查参考。

把这张图落到操作上，典型流程是：先 Break.List 确认资源，再按“执行断点用 Onchip、数据监控用 /Data、非关键点用 /Soft”的原则分配，最后用 Group 模式冻结同组核并同时查看两核现场。若命中后仍无法判断，可结合 Frame.View 查看调用栈、Var.View 查看共享变量，形成从触发到定位的闭环。