引言
在嵌入式开发或系统编程中，控制程序中代码和数据的内存布局是非常重要的。在一些情况下，我们希望将特定的函数或变量放置在特定的内存区域，比如让某些关键的初始化代码放在一个只读段中，或者将某些数据放入高速缓存友好的区域。GCC 提供的 __attribute__((section("secname"))) 是实现这种精细化控制的一个强大工具。
在这篇文章中，我们将深入讨论 __attribute__((section("secname"))) 的工作原理、应用场景以及使用方法。
工作原理
GCC 的 __attribute__((section("secname"))) 属性允许开发者将函数或变量放入特定的节中，而不是让编译器按照默认规则进行放置。使用这个属性时，开发者可以指定节名称，并由链接器控制这些节如何映射到最终的可执行文件或目标文件中的不同内存区域。__attribute__((section("secname"))) 属性的基本语法如下：
__attribute__((section("secname")))
其中，secname 是目标节的名称，通常由开发者定义。
代码演示
#include <stdio.h>
// 将变量放入 "my_data_section" 段
int my_global_var __attribute__((section("my_data_section"))) = 100;
// 将函数放入 "my_code_section" 段
void __attribute__((section("my_code_section"))) my_function() {
printf("Hello from my_function!\n");
}
int main() {
printf("my_global_var: %d\n", my_global_var);
my_function();
return 0;
}
在这个示例中：
my_global_var被放置在my_data_section节。my_function被放置在my_code_section节。
首先，我们编译这个 C 代码，并生成一个目标文件。
gcc -c -o example.o example.c
然后，链接生成可执行文件：
gcc -o example example.o
我们可以使用 objdump 工具查看目标文件 example.o 或最终的可执行文件 example 中的节信息。
首先，使用以下命令查看节头表，确认我们自定义的节是否存在：
[root@localhost section]# objdump -h example
example: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 0000001c 0000000000400238 0000000000400238 00000238 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 0000000000400254 0000000000400254 00000254 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.gnu.build-id 00000024 0000000000400274 0000000000400274 00000274 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gnu.hash 0000001c 0000000000400298 0000000000400298 00000298 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynsym 000000a8 00000000004002b8 00000000004002b8 000002b8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynstr 0000007a 0000000000400360 0000000000400360 00000360 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version 0000000e 00000000004003da 00000000004003da 000003da 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version_r 00000020 00000000004003e8 00000000004003e8 000003e8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.dyn 00000060 0000000000400408 0000000000400408 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rela.plt 00000030 0000000000400468 0000000000400468 00000468 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .init 0000001b 0000000000400498 0000000000400498 00000498 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .plt 00000030 00000000004004c0 00000000004004c0 000004c0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .text 00000195 00000000004004f0 00000000004004f0 000004f0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 my_code_section 00000011 0000000000400685 0000000000400685 00000685 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .fini 0000000d 0000000000400698 0000000000400698 00000698 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .rodata 0000003b 00000000004006a8 00000000004006a8 000006a8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .eh_frame_hdr 00000044 00000000004006e4 00000000004006e4 000006e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .eh_frame 00000108 0000000000400728 0000000000400728 00000728 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .init_array 00000008 0000000000600e00 0000000000600e00 00000e00 2**3
CONTENTS, ALLOC, LOAD, DATA
19 .fini_array 00000008 0000000000600e08 0000000000600e08 00000e08 2**3
CONTENTS, ALLOC, LOAD, DATA
20 .dynamic 000001d0 0000000000600e10 0000000000600e10 00000e10 2**3
CONTENTS, ALLOC, LOAD, DATA
21 .got 00000020 0000000000600fe0 0000000000600fe0 00000fe0 2**3
CONTENTS, ALLOC, LOAD, DATA
22 .got.plt 00000028 0000000000601000 0000000000601000 00001000 2**3
CONTENTS, ALLOC, LOAD, DATA
23 .data 00000004 0000000000601028 0000000000601028 00001028 2**0
CONTENTS, ALLOC, LOAD, DATA
24 my_data_section 00000004 000000000060102c 000000000060102c 0000102c 2**2
CONTENTS, ALLOC, LOAD, DATA
25 .bss 00000008 0000000000601030 0000000000601030 00001030 2**0
ALLOC
26 .comment 0000002d 0000000000000000 0000000000000000 00001030 2**0
CONTENTS, READONLY
27 .gnu.build.attributes 00001db8 0000000000a01038 0000000000a01038 00001060 2**2
CONTENTS, READONLY
可以看到，my_code_section 和 my_data_section 节已经成功出现在节头表中。
接下来，使用以下命令反汇编代码，查看 my_function 和 my_global_var 的内存位置：
[root@localhost section]# objdump -d example | grep -A 10 my_code_section
Disassembly of section my_code_section:
0000000000400685 <my_function>:
400685: 55 push %rbp
400686: 48 89 e5 mov %rsp,%rbp
400689: bf b8 06 40 00 mov $0x4006b8,%edi
40068e: e8 3d fe ff ff callq 4004d0 <puts@plt>
400693: 90 nop
400694: 5d pop %rbp
400695: c3 retq
输出结果可能如上（仅展示相关部分）：在 .my_code_section 节，我们可以看到 my_function 函数被放置在地址 0x400685 处。
接下来，查看变量 my_global_var 所在的节信息：
[root@localhost section]# objdump -s -j my_data_section example
example: file format elf64-x86-64
Contents of section my_data_section:
60102c 64000000 d...
可以看到，my_global_var 被放置在 .my_data_section 节的地址 0x60102c，其值 0x64 对应于十进制的 100。
通过上面的反汇编结果和节表查看，我们可以确认：
my_function确实被放入了my_code_section，并且其代码在内存地址0x400685处开始。my_global_var确实被放入了my_data_section，其内存地址为0x60102c，并且初始值为100。
总结
通过 GCC 的 __attribute__((section("secname"))) 机制，我们可以将特定的变量和函数放置到指定的内存节中。结合 objdump 工具，我们可以轻松查看这些函数和变量在内存中的位置。单独使用 __attribute__((section("secname")) 指定节名虽然有时候可以完成我们的特定目的，但是为了能真正控制这些节的内存布局，我们还需要借助链接器脚本。在链接器脚本中，可以指定每个节的内存地址及其大小，有关链接器脚本的内容可参考 【Linker Script 脚本秘籍 | 语法深度解析与实战】。
如果你正在从事嵌入式开发或编写对内存布局有严格要求的程序，熟练掌握 __attribute__((section("secname"))) 将为你带来极大的便利。
