3. 调试符号与ELF文件解析
在 Ozone 中打开一个 .elf 文件时，调试器并不是“直接运行程序”，而是先把这个 ELF 当作一份可解析的调试数据库来读取。理解 ELF 的内部结构，是排查“符号加载失败”“源码对不上”“断点打不上”这类问题的前提。本节围绕编译输出、调试信息、符号表、源文件路径映射和加载失败排查五个环节展开。
一、ELF 里到底有什么
ELF（Executable and Linkable Format）是编译链接后的最终产物，它由文件头、程序头表、节区头表以及若干节区（section）组成。对调试而言，真正关键的不是可执行代码本身，而是下面几类节区：
- .text / .data / .bss：代码段、已初始化数据段、未初始化数据段，决定变量和函数在目标内存中的地址。
- .debug_info：DWARF 调试信息主体，描述类型、变量、函数、作用域、行号表。
- .debug_line：行号程序，把机器指令地址映射回源文件与行号。
- .debug_abbrev / .debug_str：DWARF 缩写表与字符串表，供 .debug_info 引用。
- .symtab / .strtab：符号表与符号名字符串表，包含函数、全局变量、节区符号。
- .debug_frame / .eh_frame：调用栈展开信息，决定 Ozone 能否正确回溯调用栈。
Ozone 加载 ELF 时，会同时读取符号表和 DWARF 调试信息。符号表提供“名字到地址”的快速索引，DWARF 提供“地址到源码、类型、变量”的详细描述。两者缺一不可：只有符号表，能看函数名但看不到变量类型和源码行；只有 DWARF，能看源码但符号浏览效率低。
二、编译输出与调试信息生成
调试信息是否完整，取决于编译和链接选项。以 GCC/Clang 为例，常用组合如下：
# 编译：生成 DWARF 调试信息，不优化，保留帧指针
arm-none-eabi-gcc -c -g3 -gdwarf-4 -O0 -fno-omit-frame-pointer \
-ffunction-sections -fdata-sections main.c -o main.o
# 链接：保留调试节区，生成 map 文件
arm-none-eabi-gcc -g3 -gdwarf-4 -Wl,--gc-sections \
-Wl,-Map=build/app.map -T linker.ld \
main.o driver.o -o build/app.elf这里几个参数值得注意：-g3 比 -g 多包含宏定义信息；-gdwarf-4 明确 DWARF 版本，避免工具链默认版本与 Ozone 解析器不匹配；-O0 保证变量不被优化掉，便于观察；-fno-omit-frame-pointer 让调用栈展开更可靠。若使用 -O2 且未保留调试信息，常见现象是变量显示为 <optimized out>，或断点被移动到相邻行。
-g 但配合 -O2，此时应接受部分变量不可见，并优先使用寄存器视图和反汇编视图定位问题。三、符号表与调试信息的读取
在 Ozone 中加载 ELF 后，可通过 Symbols 窗口查看已解析的符号。若怀疑符号缺失，可先用工具链自带命令核对 ELF 内容：
# 查看节区是否存在调试信息
arm-none-eabi-readelf -S build/app.elf | grep debug
# 查看符号表
arm-none-eabi-nm -n build/app.elf | head -20
# 查看某函数的 DWARF 信息
arm-none-eabi-objdump --dwarf=info build/app.elf | grep -A5 "main"如果 readelf -S 看不到 .debug_info，说明编译时没有加 -g，或链接时被 strip 掉了。如果符号表存在但 Ozone 仍不显示源码，问题通常出在行号表或源文件路径映射上。
四、源文件路径映射
DWARF 中记录的是编译时的源文件路径。如果编译在 Linux 服务器上完成，路径可能是 /home/build/project/src/main.c，而你在 Windows 上打开 Ozone，实际文件在 D:\work\project\src\main.c。此时 Ozone 找不到源文件，源码视图会显示“Source file not found”。
解决办法是配置 Source Path Mapping。在 Ozone 的工程设置中，添加一条映射规则，把编译时路径前缀替换为本地路径前缀。例如：
编译时路径: /home/build/project/
本地路径: D:\work\project\映射规则按最长前缀匹配。若存在多个构建目录，可添加多条规则。配置完成后重新加载 ELF，Ozone 会按映射后的路径查找源文件。若仍失败，可在 Ozone 的 Console 中查看它实际尝试打开的路径，据此修正映射。
五、加载失败排查清单
当 Ozone 提示符号或源码加载异常时，建议按以下顺序排查：
| 现象 | 可能原因 | 验证方法 | 处理 |
|---|---|---|---|
| 无任何符号 | ELF 被 strip 或未加 -g | readelf -S 查 .debug_info | 重新编译加 -g3，链接不加 -s |
| 有函数名无源码 | 行号表缺失或路径不匹配 | objdump --dwarf=decodedline | 配置 Source Path Mapping |
| 变量显示 optimized out | 优化等级过高 | 查看编译选项 | 调试版用 -O0，或改看寄存器 |
| 断点地址错位 | 链接脚本与加载地址不一致 | 对比 .map 与 Ozone 加载地址 | 修正链接脚本或加载配置 |
| 调用栈不完整 | 缺少 .debug_frame 或帧指针被省略 | readelf -S 查 .debug_frame | 加 -fno-omit-frame-pointer |
--gc-sections 会删除未被引用的节区，若某函数仅被调试器引用而未被代码调用，可能被回收，导致符号消失。排查时可临时关闭该选项对比。掌握 ELF 结构与 Ozone 的加载逻辑后，大部分“符号加载失败”都能在几分钟内定位到具体环节：是编译没带调试信息，是链接被 strip，还是路径映射没配好。把这条链路走通，后续的断点、变量观察和调用栈分析才有可靠基础。