GDB环境中function.part.10含义及无法显示代码行号问题咨询

这个是GCC编译器开启较高优化等级后产生的拆分函数后缀。编译器在处理较大的函数时，为了提升执行效率会将单个函数拆分为多个独立的代码块做针对性优化，每个拆分出来的代码块都会以原函数名.part.N的格式命名，其中N是拆分块的序号。你遇到的段错误就发生在classExtractPerturbation函数拆分出的第10个代码块中。

• 补充调试符号重新编译
  这是该问题最常见的诱因，编译时未加入-g参数就不会生成调试所需的行号、变量映射信息。需要先清理所有旧编译产物（执行make clean或对应构建工具的清理指令），重新编译时全程添加-g参数。如果使用CMake、Meson等构建工具，可直接切换到Debug构建模式，该模式默认会添加调试符号并关闭影响调试的优化选项。

• 降低编译优化等级
  高优化等级（-O2、-O3等）会触发函数拆分、指令重排、变量消除等优化操作，即使携带调试符号也可能出现行号不匹配、无法定位源码的问题。调试阶段建议将优化等级调整为-O0或-O1，即可避免优化导致的调试信息丢失问题，也能消除part.N这类拆分函数名。

• 手动添加源文件搜索路径
  如果重新编译后仍提示找不到文件，可在GDB中执行dir 项目源码根目录绝对路径手动添加源码搜索路径，添加完成后再执行list命令即可正常加载对应代码。

• 临时定位技巧
  如果暂时无法重新编译，可使用addr2line工具直接根据出错地址匹配代码位置，执行命令addr2line -e ./uclcl_param_est 0x00005555556ea9bb，只要二进制文件携带调试符号就能直接输出对应的源文件路径和行号。

内容的提问来源于stack exchange，提问作者Gabriel Amâncio Hoerning