嵌入式开发中__attribute__((used))的实战应用与编译器优化陷阱解析

1. 一个被编译器“优化掉”的符号引发的血案

如果你在嵌入式开发，尤其是涉及RTOS、驱动或者复杂固件移植时，遇到过这样的场景：你明明在代码里定义了一个函数或者变量，编译链接也通过了，但程序一跑起来，对应的功能就失效了，或者链接器直接报错说找不到某个符号。你反复检查代码，确认拼写无误，确认头文件包含正确，甚至用objdump去看目标文件，发现它确实存在，但最终的可执行文件里就是没有它。这时候，你很可能已经掉进了编译器“过度优化”的陷阱里。

这个陷阱的核心在于，现代编译器（尤其是GCC、Clang这类）的优化器非常“聪明”。它的工作目标之一，就是生成尽可能精简、高效的代码。为了实现这个目标，它会进行“死代码消除”。简单来说，编译器在分析你的代码时，如果发现某个函数（或全局变量）在整个程序中没有被任何地方显式地调用或引用，它就会判定这个符号是“无用”的，进而在链接阶段将其丢弃，以节省宝贵的代码空间（在嵌入式领域，这通常是Flash）和数据空间（RAM）。

听起来很合理，对吧？但问题就出在，嵌入式系统的编程模型远比桌面应用复杂。很多关键的符号，其“使用”方式并非通过传统的C函数调用链。例如：

• 中断向量表：一个指向中断服务程序的函数指针数组。编译器看到这个数组被定义，但可能找不到谁在“调用”数组里的这些函数（因为中断是硬件触发的），于是可能把整个向量表或者其中某些条目优化掉。
• 链接脚本中指定的段内符号：你为了让某个变量或函数必须放在特定的内存地址（比如非易失性存储区NVRAM的配置区，或者一块共享内存），会在链接脚本里通过KEEP()命令来保留它。但编译器在编译单个.c文件时，并不知道链接脚本的存在。如果它认为这个符号未被使用，可能在生成.o文件时就已经将其标记为“可丢弃”的了，链接器即使看到KEEP也无能为力。
• 通过函数指针表动态调用的函数：在模块化设计或插件式架构中，核心模块通过查找一个全局的函数指针表来调用其他模块的功能。如果这个指针表只在运行时被赋值和查找，编译器在静态分析阶段可能无法追踪到这种间接调用关系，从而认为那些被注册的函数是“死代码”。
• 被汇编代码引用的C符号：你的启动文件（.s）或者某些性能关键的内联汇编，需要直接引用一个C语言中定义的函数地址或变量地址。编译器同样可能因为找不到C层面的引用而将其优化。

我亲身经历过一个典型的案例。在移植一个开源协议栈到新的MCU平台时，协议栈内部有一个精心设计的、通过宏自动注册的回调函数表。编译一切正常，但运行时发现某些特定事件永远无法触发回调。用arm-none-eabi-nm工具查看最终的.elf文件，发现那些回调函数符号根本不存在。问题根源就是：注册这些回调的宏只生成了一个结构体数组，而编译器认为这个数组没有被任何“语句”使用，遂将其连同里面的函数指针一起清理了。这就是标题里所说的，编译器以为“没用”的关键符号。

而__attribute__((used))，就是GCC和Clang编译器提供给我们，用来对抗这种“善意但误判”的优化的利器。你可以把它理解为贴在符号上的一个“免死金牌”，告诉编译器：“嘿，这个符号我后面有用（可能是以一种你看不见的方式），请务必保留它，别管你的静态分析结果如何。”

2.__attribute__((used))的本质：给编译器的强制保留指令

__attribute__是GCC（以及兼容GCC的编译器如Clang）提供的一种强大语法，用于向编译器传递关于函数、变量、类型等的特殊指令。((used))是众多属性中的一个，它的官方语义非常明确：强制将所修饰的符号输出到目标文件（.o文件）中，即使编译器认为该符号未被引用。

这行代码：

__attribute__((used)) void my_critical_function(void) { /* ... */ }

或者

int __attribute__((used)) vital_config_data;

就是在对编译器的优化器说：“停下你的死代码消除，这个符号我必须保留。”

它的工作原理发生在编译流程的早期。当编译器前端（解析和语义分析）处理完你的代码，生成中间表示（IR）后，优化器会开始工作。used属性作为一个元数据，会被附加到对应的符号上。当优化器执行“内部符号消除”或“无用代码删除”等优化通道时，它会检查符号的属性。如果看到used属性，就会跳过对该符号的消除操作，确保它能够进入后续的汇编代码生成阶段，并最终出现在目标文件.o的符号表里。

这里必须厘清一个关键概念：__attribute__((used))作用于编译阶段，影响的是单个.o文件的内容。它解决的是“编译器在生成这个目标文件时，就把符号给扔了”的问题。而链接脚本里的KEEP()命令，作用于链接阶段，是指导链接器在合并所有.o文件时，不要丢弃某个输入段（section）或符号。两者是互补关系，而非替代关系。一个典型的保留链条是：

1. 编译期：用used属性确保符号进入.o文件的特定段（比如.data或.text）。
2. 链接期：在链接脚本中，用KEEP(*(.my_special_section))确保包含该符号的整个输入段不会被链接器丢弃。

如果只在链接脚本里KEEP，但编译器压根没把这个符号放到.o文件里，那么KEEP也无物可保。所以，对于上述提到的、编译器容易误判的符号，used属性通常是第一道，也是必要的防线。

3. 实战场景：哪些符号必须贴上“免死金牌”

理解了原理，我们来看看在嵌入式开发中，具体哪些地方需要毫不犹豫地使用__attribute__((used))。我将它们分为四大类。

3.1 中断服务程序与向量表

这是最经典的应用场景。中断向量表通常在一个独立的C文件或汇编文件中定义，例如：

// interrupt_vectors.c void __attribute__((used)) SysTick_Handler(void) { /* ... */ } void __attribute__((used)) USART1_IRQHandler(void) { /* ... */ } // ... 其他中断处理函数 // 向量表通常用指针数组表示，也可能需要修饰 extern void (* const __attribute__((used)) g_pfnVectors[])(void);

即使你在启动文件或链接脚本里通过绝对地址引用了g_pfnVectors，编译器在编译interrupt_vectors.c时，可能因为看不到这些外部引用（特别是跨文件的复杂引用），而认为SysTick_Handler等函数是孤立的、未被调用的。加上used属性是确保它们存在的保险措施。

注意：对于中断处理函数，一些MCU厂商的HAL库或IDE（如STM32 CubeIDE的weak声明）可能已经通过其他机制（如weak别名或特殊的段名）保证了其存在。但当你需要自定义一个非标准的中断，或者在使用纯裸机编程、高度定制的RTOS时，手动添加used属性是最直接可靠的方法。

3.2 链接脚本中显式定位的变量与函数

假设你的产品需要一块在芯片复位后依然保持数据的配置存储区，你可能会在链接脚本里定义：

MEMORY { ... NVRAM (rw) : ORIGIN = 0x0800F000, LENGTH = 4K } SECTIONS { ... .nvram_config (NOLOAD) : { KEEP(*(.nvram_config)) } > NVRAM }

然后在C代码中：

// config.c // 错误的做法：编译器可能优化掉 config_data nvram_config_t config_data; // 正确的做法：使用used属性并指定段 nvram_config_t __attribute__((used, section(“.nvram_config”))) config_data = {0};

这里我们同时使用了used和section属性。used确保config_data这个符号一定会被生成到config.o中；section属性则告诉编译器把它放到一个叫.nvram_config的段里，这样链接脚本中的KEEP(*(.nvram_config))才能捕获到它。缺少used属性，编译器可能直接不生成这个变量，后续的一切都无从谈起。

3.3 模块注册表与插件架构中的回调函数

在为了解耦而设计的系统中，常见一种“注册表”模式。模块A并不直接调用模块B的函数，而是让模块B在初始化时，将自己的函数指针注册到一个全局的数组中。

// callback_registry.h typedef void (*callback_t)(int event_id); void register_callback(int id, callback_t cb); // module_b.c static void __attribute__((used)) my_private_handler(int event) { /* ... */ } void module_b_init(void) { // 注册的是 static 函数！编译器在 module_b.c 内看不到其他调用点。 register_callback(EVENT_X, my_private_handler); }

my_private_handler是一个static函数，意味着它只在module_b.c文件内可见。编译器在分析module_b.c时，只看到它被取地址后传给了register_callback。对于一些激进的优化级别（如-Os，-O2及以上），编译器可能会认为“这个函数地址被传出去了，但传出去之后有没有被调用我分析不了，为了安全（减少体积），我假设它没被调用，删掉吧”。给这个static函数加上used属性，就是明确禁止编译器做这个假设。

3.4 被汇编代码直接引用的C符号

在写启动文件 (startup.s) 或者进行极致性能优化时，可能会在汇编代码里直接使用C变量的地址或跳转到C函数的地址。

; startup.s ldr r0, =_estack ; 引用C链接脚本中定义的栈顶符号 ldr r1, =SystemInit ; 引用C函数 SystemInit blx r1

// system.c // 必须确保 SystemInit 被保留，即使main函数没有直接调用它（可能由汇编调用） void __attribute__((used)) SystemInit(void) { /* ... */ }

汇编器在处理.s文件时，会将SystemInit视为一个未定义的外部符号。如果编译器在编译system.c时把SystemInit优化掉了，那么链接器就会报“未定义的引用”错误。used属性可以杜绝这种情况。

4. 不止于used：相关属性与链接脚本的配合之道

__attribute__((used))并非孤军奋战。在实际工程中，我们经常需要结合其他属性和链接脚本，形成一套完整的符号保留策略。

4.1usedvsweak：默认实现与强制保留

weak（弱符号）属性是另一个关键角色。它常用于定义库函数的默认实现或中断处理程序的默认桩函数。链接时，如果存在同名的强符号（没有weak属性的符号），弱符号会被覆盖。

// 库提供的默认、可能为空的中断处理程序 void __attribute__((weak)) TIM2_IRQHandler(void) { while(1); // 或者什么都不做 } // 用户可以在自己的代码中提供强实现，覆盖上面的弱实现 void TIM2_IRQHandler(void) { // 没有weak，是强符号 // 用户的具体处理逻辑 }

一个常见的困惑是：弱符号需要加used吗？答案是：通常需要。编译器对待弱符号时，同样会进行死代码消除分析。如果它认为这个弱函数没有被任何地方调用（包括潜在的、通过向量表的调用），它仍然可能将其优化掉。然而，这个弱函数存在的意义恰恰是“作为默认实现被链接器选择”。如果它被优化掉了，当用户没有提供强实现时，链接器就找不到任何TIM2_IRQHandler的实现，会导致链接错误。因此，更稳健的做法是：

void __attribute__((weak, used)) TIM2_IRQHandler(void) { while(1); }

这样，既保证了它作为可覆盖的默认实现，又保证了它至少会存在于目标文件中，供链接器使用。

4.2section属性：将符号送入特定段落

如前所述，section(“段名”)属性用于将符号放置到自定义的段中。这通常与链接脚本中的KEEP()配合使用。

// 将关键数据放入一个不会被零初始化的段 const uint32_t __attribute__((used, section(“.noinit”))) boot_counter;

在链接脚本中：

.noinit (NOLOAD) : { KEEP(*(.noinit)) } > RAM

这种组合拳实现了精细化的内存控制：used保证符号存在，section指定其归宿，链接脚本的KEEP和(NOLOAD)则控制链接和加载行为。

4.3 链接脚本中的KEEP：链接阶段的守护神

务必再次明确分工：

• __attribute__((used))：编译阶段，对单个源文件生效，命令编译器“必须生成这个符号”。
• KEEP()：链接阶段，在链接脚本中生效，命令链接器“不要丢弃这个输入段或符号”。

KEEP()的语法是KEEP(*(section_name))或KEEP(symbol_name)。它像是链接器垃圾回收机制的一道白名单。即使一个段没有被任何其他段引用（即被认为是“孤儿段”），只要被KEEP()包裹，它就会被保留在最终镜像中。

一个完整的例子：保留自定义的构造函数数组有些系统需要在main()之前自动执行一些初始化函数。我们可以创建一个函数指针数组，并用链接脚本保证它被保留。

// init_array.c typedef void (*init_func_t)(void); // 定义一个存放初始化函数的段 #define INIT_SECTION __attribute__((used, section(“.init_array”))) // 两个初始化函数 void INIT_SECTION early_uart_init(void) { /* ... */ } void INIT_SECTION memory_pool_init(void) { /* ... */ } // 链接脚本中 .init_array : { KEEP(*(SORT_BY_INIT_PRIORITY(.init_array.*))) // 可能还需要排序 KEEP(*(.init_array)) } > FLASH

启动代码会在调用main之前，遍历.init_array段中的每个函数指针并执行。这里，used确保了early_uart_init和memory_pool_init这两个符号（实际上是它们的地址）会被放入.o文件的.init_array段；链接脚本的KEEP则确保这个段不会被链接器丢弃。

5. 排查与验证：如何确认符号真的被保留了

当你怀疑符号被优化，或者加了属性后想确认是否生效，你需要一套排查方法。以下是我常用的工具链，基于GNU工具链（arm-none-eabi-）。

1. 查看目标文件 (.o) 的符号表这是检查used属性是否在编译阶段起效的第一步。

arm-none-eabi-nm -g your_object_file.o

查看输出中是否有你定义的符号。nm命令会列出符号。如果符号存在，你会看到它的类型（如T表示文本/代码段，D表示已初始化数据，B表示未初始化数据）。如果找不到，说明编译器在生成这个.o文件时就已经把它剔除了，used属性可能没加对位置（比如加在了声明而非定义上），或者语法错误。

2. 查看链接后的映射文件 (.map)映射文件是链接器生成的“地图”，详细记录了所有段、符号的最终地址和大小。在链接命令中加入-Wl,-Map=output.map生成。 在output.map中搜索你的符号名。如果找到了，并且有具体的地址（不是*ABS*或*UND*这类未定义标记），说明它成功进入了最终的可执行文件。这是验证KEEP()和整个保留链条是否生效的终极手段。

3. 反汇编查看最终二进制对于函数，最直观的方法是反汇编：

arm-none-eabi-objdump -d your_elf_file.elf | grep -A 20 “<your_function_name>:”

如果能看到该函数的汇编指令，那就100%确认保留了。对于变量，可以查看数据段：

arm-none-eabi-objdump -s -j .data your_elf_file.elf # 查看.data段内容

4. 一个常见的坑：used属性加错了地方__attribute__语法必须紧跟在符号的声明或定义上。常见错误是加在了函数或变量的“声明”（在头文件中），而没有加在“定义”（在.c文件中）。对于要保留的符号，属性必须加在定义处。因为决定符号是否生成的，是它的定义。

// header.h extern void critical_func(void); // 声明，这里加used没用 // source.c // 正确：属性加在定义处 void __attribute__((used)) critical_func(void) { // ... }

5. 编译器优化级别的影响-O0（默认，无优化）通常不会进行激进的死代码消除。问题往往在开启-Os（优化大小）、-O2、-O3时出现。因此，在调试此类问题时，可以尝试先用-O0编译，如果问题消失，就基本可以确定是优化导致。然后逐步添加used属性，再用高优化级别验证。

6. 举一反三：其他编译器与语言中的类似机制

GCC/Clang的__attribute__((used))是嵌入式领域最常用的，但并非唯一。了解其他环境下的等效机制很有必要。

• IAR Embedded Workbench：使用__root关键字。例如：__root void essential_function(void);。__root的含义与used非常类似，强制链接器保留该符号。
• Keil MDK (ARMCC/ARMClang)：ARMCC编译器通常使用__attribute__((used))（兼容GCC语法）。在较旧的版本或特定语境下，也可能使用#pragma指令，但used属性是主流且推荐的方式。
• Microsoft Visual C++：在桌面或嵌入式Windows开发中，VC++使用__declspec(selectany)来处理类似“唯一定义”的问题，但对于“强制保留”，更多依赖于链接器选项（如/INCLUDE符号）或在定义时确保有显式引用。没有直接的used等价物，因为VC++的链接模型有所不同。
• C++ 中的[[gnu::used]]：在C++11及以后的标准中，可以使用双括号的属性语法[[gnu::used]]，这是GCC特性的标准化写法，功能与__attribute__((used))完全相同。

经验之谈：在跨平台或可移植性要求高的代码中，为了同时适配GCC和IAR，我们通常会使用宏来包装：

#ifdef __ICCARM__ // IAR编译器 #define KEEP_SYMBOL __root #else // GCC/Clang #define KEEP_SYMBOL __attribute__((used)) #endif KEEP_SYMBOL void must_keep_function(void);

这样，同一份代码在不同工具链下都能正确保留关键符号。

7. 总结与最佳实践：何时用，怎么用，何时不用

经过以上分析，我们可以总结出关于__attribute__((used))的清晰使用指南。

必须使用used的场景：

1. 任何可能被链接脚本、汇编代码或其他非C直接调用方式引用的函数和全局变量。这是最高原则。
2. 中断服务程序（ISR），除非你百分百确认编译环境（如芯片厂商的HAL库）已通过其他机制保证其保留。
3. 放置在自定义链接段（通过section属性）中的符号。确保它先能被生成到.o文件。
4. 通过指针数组、注册表等方式间接调用的static函数。防止编译器因无法追踪间接调用而将其删除。
5. weak属性的默认实现函数。确保在用户未覆盖时，链接器能找到这个默认实现。

使用时的注意事项：

1. 加在定义，而非声明：确保属性修饰的是符号的实体定义。
2. 与static结合要小心：static函数加used是常见操作。但static变量加used要谨慎，因为这可能会阻止编译器对该变量进行其他有益的优化（比如合并到寄存器）。仅在确实需要该变量的地址被外部引用（例如通过链接脚本获取其地址）时才这样做。
3. 不要滥用：used会阻止优化。如果你给一个真正无用的函数加上used，就会增加最终固件的大小。只在确有必要时使用。
4. 配合链接脚本：记住，used是“保送”符号进入.o文件，链接脚本的KEEP是“保送”段或符号进入最终镜像。两者常常需要联手。
5. 代码可读性：对于大量需要保留的符号（比如一整个中断向量表），可以考虑定义一个清晰的宏，如#define ISR_HANDLER __attribute__((used, weak))，让代码意图更明确。

调试心法：当你遇到“未定义的引用”或运行时功能缺失，而代码逻辑看起来完全正确时，第一时间应该怀疑“符号是否被优化了”。按照“查看.o文件符号表 -> 检查映射文件 -> 反汇编验证”的流程，结合调整优化等级，能快速定位这类隐蔽的问题。

__attribute__((used))这个看似简单的“第16条军规”（源自C语言的未定义行为列表？这里是一种比喻，强调其重要性和隐蔽性），是嵌入式开发者从编译器手中夺回控制权的重要工具。它背后体现的是对编译-链接过程的深刻理解：你的代码不仅要写给机器和人看，还要写给那个试图“帮你”优化代码的编译器看。在资源受限、控制权至上的嵌入式世界，明确地告诉编译器“别动我的东西”，有时就是最优雅的解决方案。