为何GDB显示错误函数名？Cortex-M7启动代码调试异常

问题现象 #

• 汇编代码中bl SystemInit位于Reset_Handler符号的第179行，Uart_Handler实际定义在第164行
• 使用--gstabs选项汇编生成调试信息
• QEMU通过-S参数启动CPU并停在初始状态，GDB连接后出现矛盾：
  • info reg显示pc寄存器明确指向0x4e，对应ELF文件中的符号0000004e T Reset_Handler
  • GDB却显示当前停在第179行的Uart_Handler ()，但行号是正确的
  • 执行disassemble命令能正常显示正确的Reset_Handler函数名

可能原因 #

1. GSTABS调试格式的局限性
   GSTABS是较老旧的调试信息格式，对于地址间隔极小的符号（本例中Uart_Handler和Reset_Handler仅相差4字节），GDB初始解析时容易出现地址匹配偏差，错误关联到前一个符号。

2. GDB初始符号查找的快速策略
   GDB连接后首次解析PC对应的符号时，可能采用了快速匹配逻辑（比如匹配小于等于PC值的最近符号），没有严格结合行号与符号的关联关系。而disassemble命令会触发精确的符号+行号匹配，因此能显示正确结果。

3. 汇编符号的调试范围未明确标记
   如果汇编代码中没有为每个函数符号明确指定范围（比如未使用.type和.size指令），调试器可能无法准确识别每个符号的地址边界，导致地址归属混淆。

解决建议 #

• 切换到DWARF调试格式：放弃--gstabs，改用--gdb参数汇编代码，生成DWARF格式的调试信息。DWARF是GDB推荐的现代调试格式，对符号地址与行号的关联处理更精准，能避免这类老格式的兼容性问题。
• 强制刷新GDB符号解析：GDB连接后，执行frame命令手动刷新当前栈帧信息，或者执行set $pc = 0x4e（即使PC值未变），可触发GDB重新解析符号，显示正确的函数名。
• 完善汇编符号的范围标记：在汇编代码中为每个处理函数添加明确的类型和大小标记，帮助调试器识别符号边界：

  .type Uart_Handler, %function
  Uart_Handler:
      ; Uart_Handler的代码逻辑
  .size Uart_Handler, .-Uart_Handler
  
  .type Reset_Handler, %function
  Reset_Handler:
      ; Reset_Handler的代码逻辑
  .size Reset_Handler, .-Reset_Handler
  

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