gcc的attribute编绎属性

偏执的太偏执、 2021-12-22 03:23 235阅读 0赞

### [gcc的\_\_attribute\_\_编绎属性][gcc_attribute] ###

要了解Linux Kernel代码的分段信息，需要了解一下gcc的\_\_attribute\_\_的编绎属性，\_\_attribute\_\_主要用于改变所声明或定义的函数或数据的特性，它有很多子项，用于改变作用对象的特性。比如对函数，noline将禁止进行内联扩展、noreturn表示没有返回值、pure表明函数除返回值外，不会通过其它（如全局变量、指针）对函数外部产生任何影响。但这里我们比较感兴趣的是对代码段起作用子项section。

\_\_attribute\_\_的section子项的使用格式为：

\_\_attribute\_\_((section("section\_name")))

其作用是将作用的函数或数据放入指定名为"section\_name"输入段。

这里还要注意一下两个概念：输入段和输出段

输入段和输出段是相对于要生成最终的elf或binary时的Link过程说的，Link过程的输入大都是由源代码编绎生成的目标文件.o，那么这些.o文件中包含的段相对link过程来说就是输入段，而Link的输出一般是可执行文件elf或库等，这些输出文件中也包含有段，这些输出文件中的段就叫做输出段。输入段和输出段本来没有什么必然的联系，是互相独立，只是在Link过程中，Link程序会根据一定的规则（这些规则其实来源于Link Script），将不同的输入段重新组合到不同的输出段中，即使是段的名字，输入段和输出段可以完全不同。

其用法举例如下：

int var \_\_attribute\_\_((section(".xdata"))) = 0;

这样定义的变量var将被放入名为.xdata的输入段，（注意：\_\_attribute\_\_这种用法中的括号好像很严格，这里的几个括号好象一个也不能少。）

static int \_\_attribute\_\_((section(".xinit"))) functionA(void)

.....  
\}

这个例子将使函数functionA被放入名叫.xinit的输入段。

需要着重注意的是，\_\_attribute\_\_的section属性只指定对象的输入段，它并不能影响所指定对象最终会放在可执行文件的什么段。

2. Linux Kernel源代码中与段有关的重要宏定义

Ａ. 关于\_\_init、\_\_initdata、\_\_exit、\_\_exitdata及类似的宏

打开Linux Kernel源代码树中的文件：include/init.h，可以看到有下面的宏定议：

\#define \_\_init \_\_attribute\_\_ ((\_\_section\_\_ (".init.text"))) \_\_cold

\#define \_\_initdata \_\_attribute\_\_ (( \_\_section\_\_ (".init.data")))

\#define \_\_exitdata \_\_attribute\_\_ (( \_\_section\_\_ (".exit.data")))

\#define \_\_exit\_call \_\_attribute\_used\_\_ \_\_attribute\_\_ (( \_\_section\_\_ (".exitcall.exit")))

\#define \_\_init\_refok oninline \_\_attribute\_\_ ((\_\_section\_\_ (".text.init.refok")))

\#define \_\_initdata\_refok \_\_attribute\_\_ ((\_\_section\_\_ (".data.init.refok")))

\#define \_\_exit\_refok noinline \_\_attribute\_\_ ((\_\_section\_\_ (".exit.text.refok")))

.........

\#ifdef MODULE

\#define \_\_exit \_\_attribute\_\_ (( \_\_section\_\_ (".exit.text"))) \_\_cold

\#else

\#define \_\_exit \_\_attribute\_used\_\_ \_\_attribute\_\_ ((\_\_section\_\_ (".exit.text"))) \_\_cold

\#endif

对于经常写驱动模块或翻阅Kernel源代码的人，看到熟悉的宏了吧：\_\_init, \_\_initdata, \_\_exit, \_\_exitdata。

\_\_init 宏最常用的地方是驱动模块初始化函数的定义处，其目的是将驱动模块的初始化函数放入名叫.init.text的输入段。对于\_\_initdata来说，用于数据定义，目的是将数据放入名叫.init.data的输入段。其它几个宏也类似。另外需要注意的是，在以上定意中，用\_\_section\_\_代替了 section。还有其它一些类似的宏定义，这里不一一列出，其作用都是类似的。

Ｂ. 关于initcall的一些宏定义

在该文件中，下面这条宏定议更为重要，它是一条可扩展的宏：

\#define \_\_define\_initcall(level,fn,id) /

static initcall\_t \_\_initcall\_\#\#fn\#\#id \_\_attribute\_used\_\_ /

\_\_attribute\_\_ ((\_\_section\_\_(".initcall" level ".init"))) = fn

这条宏带有3个参数：level,fn, id，分析该宏可以看出：

１.其用来定义类型为initcall\_t的static函数指针，函数指针的名称由参数fn和id决定：\_\_initcall\_\#\#fn\#\#id，这就是函数指针的名称，它其实是一个变量名称。从该名称的定义方法我们其学到了宏定义的一种高级用法，即利用宏的参数产生名称，这要借助于"\#\#"这一符号组合的作用。

２. 这一函数指针变量放入什么输入段呢，请看\_\_attribute\_\_ ((\_\_section\_\_ (".initcall" levle ".init")))，输入段的名称由level决定，如果level="1"，则输入段是.initcall1.init，如果level="3s"，则输入段是.initcall3s.init。这一函数指针变量就是放在用这种方法决定的输入段中的。

３. 这一定义的函数指针变量的初始值是什么叫，其实就是宏参数fn，实际使用中，fn其实就是真实定义好的函数。

该宏定义并不直接使用，请看接下来的这些宏定义：

\#define pure\_initcall(fn) \_\_define\_initcall("0",fn,0)  
\#define core\_initcall(fn) \_\_define\_initcall("1",fn,1)  
\#define core\_initcall\_sync(fn) \_\_define\_initcall("1s",fn,1s)  
\#define postcore\_initcall(fn) \_\_define\_initcall("2",fn,2)  
\#define postcore\_initcall\_sync(fn) \_\_define\_initcall("2s",fn,2s)  
\#define arch\_initcall(fn) \_\_define\_initcall("3",fn,3)  
\#define arch\_initcall\_sync(fn) \_\_define\_initcall("3s",fn,3s)  
\#define subsys\_initcall(fn) \_\_define\_initcall("4",fn,4)  
\#define subsys\_initcall\_sync(fn) \_\_define\_initcall("4s",fn,4s)  
\#define fs\_initcall(fn) \_\_define\_initcall("5",fn,5)  
\#define fs\_initcall\_sync(fn) \_\_define\_initcall("5s",fn,5s)  
\#define rootfs\_initcall(fn) \_\_define\_initcall("rootfs",fn,rootfs)  
\#define device\_initcall(fn) \_\_define\_initcall("6",fn,6)  
\#define device\_initcall\_sync(fn) \_\_define\_initcall("6s",fn,6s)  
\#define late\_initcall(fn) \_\_define\_initcall("7",fn,7)  
\#define late\_initcall\_sync(fn) \_\_define\_initcall("7s",fn,7s)

这些宏定义出来是为了方便的使用\_\_define\_initcall宏定义的，上面每条宏第一次使用时都会产生一个新的输入段。

接下来还有一条

\#define \_\_initcall(fn) device\_initcall(fn)  
这一条其实只是定义了另一个别名，即平常使用的\_\_initcall其实就是这儿的device\_initcall，用它定义的函数指定位于段.initcall6.init中。

Ｃ. \_\_setup宏的来源及使用

\_\_setup这条宏在Linux Kernel中使用最多的地方就是定义处理Kernel启动参数的函数及数据结构，请看下面的宏定义：

\#define \_\_setup\_param(str, unique\_id, fn, early) /  
static char \_\_setup\_str\_\#\#unique\_id\[\] \_\_initdata \_\_aligned(1) = str; /  
static struct obs\_kernel\_param \_\_setup\_\#\#unique\_id /  
\_\_used \_\_section(.init.setup) /  
\_\_attribute\_\_((aligned((sizeof(long))))) /  
= \{ \_\_setup\_str\_\#\#unique\_id, fn, early \}

\#define \_\_setup(str, fn) /  
\_\_setup\_param(str, fn, fn, 0)

使用Kernel中的例子分析一下这两条定义：

\_\_setup("root=",root\_dev\_setup);

这条语句出现在init/do\_mounts.c中，其作用是处理Kernel启动时的像root=/dev/mtdblock3之类的参数的。

分解一下这条语句，首先变为：

\_\_setup\_param("root=",root\_dev\_setup,root\_dev\_setup,0);

继续分解，将得到下面这段代吗：

static char \_\_setup\_str\_root\_dev\_setup\_id\[\] \_\_initdata \_\_aligned(1) = "root=";  
static struct obs\_kernel\_param \_\_setup\_root\_dev\_setup\_id  
\_\_used \_\_section(.init.setup)  
\_\_attribute\_\_((aligned((sizeof(long)))))  
= \{ \_\_setup\_str\_root\_dev\_setup\_id, root\_dev\_setup, 0 \};

这段代码定义了两个变量：字符数组变量\_\_setup\_str\_root\_dev\_setup\_id，其初始化内容为"root="，由于该变量用\_\_initdata修饰，它将被放入.init.data输入段；另一变量是结构变量\_\_setup\_root\_dev\_setup\_id，其类型为struct obs\_kernel\_param， 该变理被放入输入段.init.setup中。结构struct struct obs\_kernel\_param也在该文件中定义如下：

struct obs\_kernel\_param \{  
const char \*str;  
int (\*setup\_func)(char \*);  
int early;  
\};

变量\_\_setup\_root\_dev\_setup\_id的三个成员分别被初始化为：

\_\_setup\_str\_root\_dev\_setup\_id －－> 前面定义的字符数组变量，初始内容为"root="。

root\_dev\_setup －－> 通过宏传过来的处理函数。

0 －－>常量0，该成员的作用以后分析。

现在不难想像内核启动时怎么处理启动参数的了：通过\_\_setup宏定义obs\_kernel\_param结构变量都被放入.init.setup 段中，这样一来实际是使.init.setup段变成一张表，Kernel在处理每一个启动参数时，都会来查找这张表，与每一个数据项中的成员str进行比较，如果完全相同，就会调用该数据项的函数指针成员setup\_func所指向的函数（该函数是在使用\_\_setup宏定义该变量时传入的函数参数），并将启动参数如root=后面的内容传给该处理函数。

来自: [http://hi.baidu.com/lj%5Fjjinl/blog/item/2b56aa2f06bbb75d4ec2267d.html][http_hi.baidu.com_lj_5Fjjinl_blog_item_2b56aa2f06bbb75d4ec2267d.html]

转载于:https://www.cnblogs.com/yuzaipiaofei/archive/2011/07/29/4124458.html

[gcc_attribute]: http://blog.csdn.net/leopard_ray/article/details/6100021
[http_hi.baidu.com_lj_5Fjjinl_blog_item_2b56aa2f06bbb75d4ec2267d.html]: http://hi.baidu.com/lj_jjinl/blog/item/2b56aa2f06bbb75d4ec2267d.html