问题现象：重定义了回调，中断却进了死循环

许多开发者在使用STM32 HAL库时都遇到过这样的场景：

  • 使用STM32CubeMX生成了工程，开启了某个外设中断（如EXTI、UART）。
  • 在stm32fxxx_it.c中找到了对应的中断服务函数，并调用了HAL库的处理函数。
  • 在用户代码中重定义了HAL_GPIO_EXTI_Callback等__weak函数，实现了自己的逻辑。
  • 编译下载后，触发中断，程序却跑飞了，或者直接进入Default_Handler死循环。

明明函数已经重定义，为什么链接器没有使用我们的强符号？这背后涉及__weak符号的链接规则、工程配置以及编译器的优化行为。

原理：__weak符号与链接器的选择

什么是__weak

在ARM Compiler（AC5/AC6）或GCC中，__weak用于声明一个弱符号。弱符号的特点是：

  • 如果链接时存在同名的强符号（普通全局符号），则使用强符号。
  • 如果不存在强符号，则使用弱符号。
  • 弱符号可以未定义，链接器不会报错（但地址可能为0）。

HAL库中大量使用__weak定义回调函数，例如：

__weak void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  /* 默认空实现，防止用户未定义时链接错误 */
}

链接器如何选择

链接器在处理目标文件时，会收集所有符号定义。对于同一个符号名：

  • 多个强符号定义 → 链接错误（重复定义）。
  • 一个强符号 + 多个弱符号 → 选择强符号。
  • 只有弱符号 → 选择任意一个弱符号（通常第一个遇到的）。

因此，只要我们提供的函数是强符号，链接器就应该使用它。但为什么有时不生效？

常见原因与排查步骤

原因1：函数签名不一致导致符号名不同

C语言没有函数重载，但符号名由编译器修饰（mangling）。如果我们的函数声明与HAL库中的声明不完全一致（参数类型、const限定符、调用约定等），编译器会生成不同的符号名，链接器自然找不到匹配的强符号。

排查方法：

  • 检查函数原型是否与HAL库头文件中的声明完全一致。
  • 使用arm-none-eabi-nm或fromelf查看目标文件中的符号名。
arm-none-eabi-nm -C build/xxx.o | grep HAL_GPIO_EXTI_Callback

如果看到两个不同的符号名（如HAL_GPIO_EXTI_Callback和HAL_GPIO_EXTI_Callback.constprop.0），说明编译器进行了优化或签名不一致。

原因2：函数被编译器优化或内联

如果我们的函数定义在头文件中，或者被声明为static，编译器可能将其内联或生成局部符号，导致链接器看不到强符号。

排查方法：

  • 确保函数定义在.c文件中，且没有static修饰。
  • 检查编译选项是否开启了LTO（链接时优化），LTO可能改变符号可见性。

原因3：链接脚本或分散加载文件未包含用户目标文件

在Keil MDK或IAR中，如果用户文件没有被添加到工程，或者链接脚本排除了某些段，强符号可能根本没有被链接。

排查方法：

  • 检查工程文件列表，确认包含用户源文件。
  • 查看生成的map文件，搜索HAL_GPIO_EXTI_Callback，确认使用的是哪个地址的符号。

原因4：中断向量表未正确重映射

有时中断服务函数本身没有被正确链接到向量表，导致跳转到默认处理程序。这通常与启动文件（startup_stm32xxx.s）中的弱定义有关。

排查方法：

  • 检查启动文件中的中断向量表，确认对应的中断处理函数名与stm32fxxx_it.c中的一致。
  • 使用调试器查看中断发生时PC指针指向的地址，与map文件对比。

原因5：多个弱符号竞争，强符号未生效

如果工程中存在多个弱符号定义（例如多个库文件都提供了弱定义），链接器可能选择了其中一个弱符号，而我们的强符号由于某些原因未被识别。

排查方法：

  • 使用nm查看所有目标文件中的符号，确认强符号确实存在。
  • 检查链接顺序，确保包含强符号的目标文件在弱符号之前被处理（某些链接器对顺序敏感）。

完整代码示例与验证

示例工程结构

  • main.c：主程序，重定义回调。
  • stm32f1xx_it.c：中断服务函数。
  • stm32f1xx_hal_gpio.c：HAL库，包含弱定义。

重定义回调（main.c）

#include "main.h"

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if (GPIO_Pin == KEY_Pin)
  {
    HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
  }
}

中断服务函数（stm32f1xx_it.c）

void EXTI0_IRQHandler(void)
{
  HAL_GPIO_EXTI_IRQHandler(KEY_Pin);
}

HAL库中的弱定义（stm32f1xx_hal_gpio.c）

__weak void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  UNUSED(GPIO_Pin);
}

验证链接结果

编译后，使用以下命令查看最终可执行文件中的符号：

arm-none-eabi-nm -C build/firmware.elf | grep HAL_GPIO_EXTI_Callback

期望输出：

08001234 T HAL_GPIO_EXTI_Callback

其中T表示该符号位于代码段，且是全局符号。如果输出为W（弱符号）或t（局部符号），则说明强符号未生效。

注意事项

  • 保持函数签名一致：包括参数类型、const、调用约定。建议直接从HAL库头文件复制声明。
  • 避免在头文件中定义函数：除非使用static inline，否则可能导致多重定义或内联。
  • 谨慎使用LTO：链接时优化可能改变符号可见性，调试阶段可暂时关闭。
  • 检查map文件：map文件是链接过程的“黑匣子”，能清晰展示符号的最终地址和来源。
  • 使用调试器确认：在中断服务函数和回调函数中设置断点，观察程序实际执行路径。
  • 注意启动文件中的弱定义：某些启动文件为中断处理函数提供了弱定义（如Default_Handler），确保你的中断服务函数名与向量表一致。

通过以上原理分析和排查步骤，相信你能快速定位并解决__weak函数重定义后中断仍进死循环的问题。嵌入式开发中，链接问题往往隐蔽，掌握工具的使用和原理的理解是关键。