使用OpenOCD调试Contiki-NG应用时gdb断点行号不匹配问题

• 编译优化参数冲突：从info source返回的编译参数可以看到，同时存在-O0（无优化，调试友好配置）和-Os（最小尺寸优化）两个互斥的优化等级参数，GCC会优先使用最后出现的优化参数，即-Os实际生效。优化会导致代码指令重排、空行/冗余代码删除、相邻行逻辑合并，最终破坏调试信息中源文件行号和二进制地址的对应关系，出现行号偏移。小型Demo调试正常是因为Demo的编译参数没有优化等级冲突，仅-O0生效。
• 模块级编译参数覆盖：Contiki-NG的全局编译配置设置了-O0后，packet-send.c所在的业务模块、CC1312r1开发板BSP配置可能单独指定了-Os，模块级参数优先级高于全局参数，最终编译时两个优化参数被同时传入编译器。
• 调试信息格式兼容性：当前使用的DWARF 2调试格式版本较老，和你使用的arm-none-eabi-gcc 9.2.1、gdb调试工具存在微小兼容性问题，可能加重行号匹配偏差。

• 排查并统一优化等级：
  1. 编译时添加V=1参数输出完整编译命令，确认packet-send.c的实际编译参数，找到-Os的添加位置：

     make TARGET=cc13x2-cc26x2 BOARD=launchpad/cc1312r1 V=1
     

  2. 删除业务模块Makefile、开发板BSP配置中额外添加的-Os参数，确保编译参数中仅保留-O0 -g用于调试。
• 全量清理重新编译：每次修改编译参数后执行make clean彻底删除旧的目标文件、核心库缓存，避免残留旧参数编译的产物导致异常。
• 升级调试信息格式：将调试参数替换为-g3 -gdwarf-4，输出更完整的调试信息，同时解决旧版DWARF的兼容性问题。
• 排查预处理代码行号偏差：如果上述操作后仍存在偏移，执行如下命令输出预处理后的完整代码，确认宏展开、条件编译逻辑是否导致实际编译行号和源文件行号不匹配：

  arm-none-eabi-gcc [packet-send.c的原有编译参数，去掉-c、-o等参数] -E packet-send.c > preprocessed.c
  

  对比preprocessed.c和原源文件的行号差异即可定位问题。

内容的提问来源于stack exchange，提问作者David Wallis