为何GDB无法检测到reload1.cc？源路径指定问题排查

以下是可能导致该问题的几个原因及对应的排查方法：

1. 最终二进制的调试信息被剥离 #

尽管编译reload1.cc时使用了-g3参数，但生成的m32c-elf-cc可能在后续流程中被strip工具移除了调试信息。GCC编译后的二进制通常会在安装或打包阶段执行strip操作以减小体积，这会清除所有调试符号。

• 排查命令：
  • 检查二进制是否被stripped：file m32c-elf-cc，如果输出包含stripped字样，说明调试信息已被移除。
  • 直接查看调试段：objdump --debugging m32c-elf-cc，如果没有输出任何调试相关内容，确认调试信息丢失。

2. reload1.cc未被编译进最终二进制 #

GCC的编译过程是模块化的，reload1.cc属于代码生成阶段的reload模块，可能存在以下情况：

• 针对m32c架构的配置中，reload1模块被条件编译跳过，未生成目标文件reload1.o。
• 链接m32c-elf-cc时，未将包含reload1.o的静态库（如libgcc.a或其他中间库）纳入链接范围。
• 排查方法：
  • 查看编译日志中是否有reload1.o的编译记录，确认该文件已生成。
  • 检查GCC编译目录下的Makefile，确认reload1.o是否被包含在m32c-elf-cc的链接依赖列表中。

3. 调试信息中的源文件路径与Docker环境不匹配 #

编译reload1.cc时，调试信息中会记录编译时的源文件绝对路径和编译目录。如果编译环境（比如构建GCC的宿主机）中的路径与Docker内的路径不一致，即使你在GDB中添加了当前路径，GDB仍会尝试按调试信息里的旧路径查找文件。

• 排查命令：
  • 查看调试信息中的路径：objdump --dwarf=info m32c-elf-cc | grep -E '(DW_AT_name|DW_AT_comp_dir)'，找到reload1.cc对应的编译目录和文件路径。
  • 解决方法：在GDB中使用set substitute-path <旧路径> <Docker内的新路径>将调试信息中的旧路径替换为当前路径。

4. Docker环境的文件权限或挂载问题 #

虽然ls命令显示文件存在，但GDB可能因文件权限不足或Docker挂载方式限制无法读取源文件：

• 检查reload1.cc的权限：ls -l /root/r8c/gcc-12.2.0/gcc/reload1.cc，确保运行GDB的用户（通常是root）有读权限。
• 确认GDB的目录配置：执行show directories查看是否已正确添加/root/r8c/gcc-12.2.0/gcc路径。

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