3. 调试信息与符号管理

在 Ozone 中做故障定位与回溯，第一步不是下断点，而是让调试器“看懂”你的程序。Ozone 本身并不解析 C 源码，它依赖编译产物中的两类元数据：符号表和DWARF 调试信息。符号表提供函数名、全局变量名与地址的对应关系，是回溯调用栈、解析函数入口的基础；DWARF 则进一步描述类型、结构体成员偏移、局部变量位置、行号与地址的映射，以及内联展开关系。缺少符号表，Ozone 只能显示裸地址；缺少 DWARF，你只能看到函数名而看不到变量和源码行。

DWARF 以调试节的形式嵌入 ELF 文件，常见节包括 .debug_info（编译单元、类型、变量、子程序）、.debug_line（地址与源文件行号映射）、.debug_abbrev（缩写表）、.debug_str（字符串池）、.debug_loc（变量位置表达式）以及 .debug_frame/.eh_frame（栈展开信息）。Ozone 加载 ELF 后，会读取这些节建立地址到源码、地址到变量位置的索引。回溯时，Ozone 依据 .debug_frame 或 .eh_frame 中的 CFI 规则逐帧恢复寄存器，再结合 .debug_info 还原函数名与参数，这就是调用栈窗口能显示完整函数链的原因。

源文件路径映射是另一个高频踩坑点。DWARF 中记录的是编译时的源文件路径，可能是绝对路径（如 /home/dev/project/src/main.c），也可能是相对路径。当工程被拷贝到另一台机器、换用不同构建目录，或使用 Docker 构建时，Ozone 按原路径找不到源文件，源码窗口就会显示“Source not found”。解决办法有三类：一是编译时使用 -fdebug-prefix-map=/build/path=. 或 -ffile-prefix-map 重写路径；二是在 Ozone 工程文件（.jdebug）中配置 Project.SetPathList() 或路径替换规则；三是保持构建目录结构一致。推荐在构建系统中统一使用 -fdebug-prefix-map，从源头消除路径差异。

优化等级对调试的影响最直接。以 -O0 编译时，每个变量都有稳定的栈位置，.debug_line 逐行映射，回溯几乎不会出错。切到 -O2 后，编译器会把局部变量放进寄存器、复用栈槽、删除死代码、内联小函数。此时 Ozone 的 Variables 窗口可能显示 <optimized out>，行号可能跳到不相关的行，调用栈可能因为尾调用优化而丢失中间帧。这不是 Ozone 的缺陷，而是 DWARF 只能描述编译器实际生成的信息。

工程配置要点可以归纳为几条可执行规则。第一，调试构建使用 -O0 -g3，-g3 包含宏定义信息，便于在 Ozone 中查看宏展开。第二，发布构建若必须优化，至少保留 -g 并加 -fno-omit-frame-pointer，保证 CFI 能正确展开栈帧。第三，避免使用 -s 或 strip 剥离调试节；若必须减小体积，可保留 .debug_frame 和符号表，仅剥离 .debug_info 中的类型细节。第四，在 Ozone 的 .jdebug 中显式指定 ELF 路径与源文件搜索路径，例如：

Project.SetDevice("STM32F407VG");
Project.SetHostIF("USB", "SN=00000000001");
Project.SetTargetIF("SWD");
Project.SetTIFSpeed(4000);
Project.AddPathSubstitute("/build/ci/workspace", "D:/proj");
File.Open("D:/proj/build/firmware.elf");

其中 Project.AddPathSubstitute 把 DWARF 中的构建路径替换为本机实际路径，是解决“Source not found”最直接的手段。加载 ELF 后，可在 Ozone 的 Debug → Debug Info 或 Symbols 窗口中确认符号是否解析成功；若函数名显示为地址，说明符号表缺失；若函数名正常但变量显示 <optimized out>，说明优化等级过高或变量被寄存器分配。

最后要理解回溯的边界。Ozone 的回溯依赖 CFI 规则和栈内存的可读性。当栈被破坏、发生栈溢出、或运行在中断上下文中且未正确保存现场时，回溯可能中断或显示错误帧。此时应结合 HardFault 状态寄存器、栈指针范围和反汇编窗口交叉验证，而不是盲目相信调用栈。调试信息管理做得好，回溯才有可信的起点；工程配置到位，Ozone 才能把地址还原成你能读懂的代码现场。