在分析之前首先查阅 RT-Thread 的官方文档RT-Thread 自动初始化机制,根据官方文档的讲述在 RTT 源码中一共使用了 6 中顺序的初始化,本文以其中的一个 INIT_APP_EXPORT(fn) 为例进行自动初始化的原理分析,其他顺序的初始化的原理与之一致。
1 知识点补充
1.1 __attribute__ 关键字
1. 关键字__attribute__ 是 GNU C 实现的编译属性设置机制,也就是通过给函数或者变量声明属性值,以便让编译器能够对要编译的程序进行优化处理。
2. 关键字 __attribute__((section(x))) 是告诉编译器,将作用的函数或数据放入指定名为 ”x” 输入段中。 举个例子,看下面一段代码:
定义了一个整形变量 a,然后将其赋值为0,而中间的 __attribute__(section(“var”)) 语句的作用是将变量 a 放入指定的段 var 中。而如果不指定变量所处的段的话,编译器就会随机将其分配在内存中。
3. __attribute__((used)) 的含义是即使它们没有被引用,也留在目标文件中,也就是告诉编译器,我声明的这个符号是需要保留的。
1.2 函数指针
1.2.1 简单的函数指针的运用 使用简单的函数指针的示例如下
从上面的结果看来,我们应该把函数名,当成指针看待。最常见的函数调用方式:fnc1(); 只是 (fnc1)(); 简写形式而已。我们之所以可以 fnc1(); 这样调用函数,只是编译器帮我们做了调整。对于函数名 fnc1 来说,不管是 fnc1 还是 fnc1 还是 &fnc1,编译器都认为他是函数指针。
1.2.2 使用 typedef 定义的函数指针 使用 typedef 定义的函数指针的示例如下
1.3 链接脚本解析 摘抄 RT-Thread 链接脚本中和本文有关的内容如下所示
其中 SORT 关键字的含义是链接器会在把文件和 section 放到 输出文件中之前按名字顺序重新排列它们。
该链接脚本部分定义了申明各种自动初始化函数在进行链接时的排列顺序,因为 RT-Thread 源码中一共定义了六种实现自动初始化功能的宏接口,详见本文最开始的表格,所以也就可以解释为什么 INIT_BOARD_EXPORT(fn) 在自动初始化的最开始,而 INIT_APP_EXPORT(fn) 在自动初始化的结尾,就是因为 SORT 关键字在起作用。
2 自动初始化原理分析 RT-Thread 源码中一共有六种不同顺序的自动初始化宏定义,如下所示
2.1 自动初始化宏定义解析 查看 RT-Thread 的源码中自动初始化宏定义,以 INIT_APP_EXPORT(fn) 为例进行分析, INIT_APP_EXPORT(fn) 的定义如下。其中宏定义中 ## 连接符号由两个井号组成,其功能是在带参数的宏定义中将两个子串(token)联接起来。
其中里面的宏定义如下
以文件 rt-thread/components/finsh/shell.c 中 Finsh 控制台初始化函数 INIT_APP_EXPORT(finsh_system_init)为例,参照上面的宏定义规则分布展开和最终结果如下
结合第1小节的补充知识,上述宏定义展开的最终结果的含义为:定一个一个 init_fn_t 类型的函数指针变量 __rt_init_finsh_system_init ,将 finsh_system_init() 函数的地址赋值给了定义的变量, 并且将该变量放到了指定的段 ".rti_fn.6" 中。 所以说只要在代码中使用 INIT_APP_EXPORT(fn) 申明的初始化函数最终都会定义在指定的段 ".rti_fn.6" 中。
2.2 组件初始化调用解析 参考官方文档 RT-Thread 启动流程,在调度器的启动函数执行时,会调用 rt_components_init() 函数对申明的各种初始化函数进行调用,RT-Thread 的启动流程如下图所示。
函数 rt_components_init() 的源码如下所示,因为没有定义宏 RT_DEBUG_INIT,所以直接将和宏 RT_DEBUG_INIT 有关的代码省略掉
其中 __rt_init_rti_board_end 和 __rt_init_rti_end 表示不同的段。在系统源码中又定义了几个空函数来申明了一些段,如下所示。
上面几个函数的导出,再加上6个自动初始化宏定义的导出,结合 1.3 小节连接脚本的分析,可以得到各个段名 和 对应的函数指针 / 宏的名字 及 前后顺序如下表所示。
我们可以通过编译生成的 map 文件对上述的分析进行验证,map 文件通常位于工程的 Debug 目录下,在 map 文件中搜索 .rti_fn* 可以找到如下所示的内容。可以看到经过排序后的各个自动初始化的段和对应的函数指针,我们前面分析的 Finsh 自动初始化的函数指针 __rt_init_finsh_system_init 就位于段 ".rti_fn.6" 中。并且从里面我们还可以看出每个函数指针都占 4 个字节的空间,因为在 32 位的系统中无论什么样的指针都占 4 个字节的空间。
再结合上面的 rt_components_init() 函数中的具体实现源码分析,我们可以看到函数指针在 for 循环的开始指向了 __rt_init_rti_board_end,也就是指向了函数 rti_board_end(),该函数没有任何操作直接返回了0。
当满足条件fn_ptr < &__rt_init_rti_end 时,fn_ptr每次循环自加1,根据生成的 map 文件可以看出下一次就指向了 __rt_init_ulog_console_backend_init ,也就是指向了函数 ulog_console_backend_init() ,该函数对 ulog输出到控制台进行了初始化。 每次循环过程中fn_ptr自加1,然后执行对应的初始化函数,一直到 fn_ptr 自加后等于 &__rt_init_rti_end时循环结束,在这个过程中就执行了各种自动初始化的代码,完成了自动初始化的任务。
为什么fn_ptr = &__rt_init_rti_board_end 这个地方要使用取地址 & 符号呢?因为 fn_ptr是一个指向函数指针的指针,根据本文 2.1 小节的分析 __rt_init_rti_board_end 是一个函数指针变量,也就是说 fn_ptr 最开始指向的是函数指针变量 __rt_init_rti_board_end 的地址,根据 map 文件也就是 0x0807523c,指针每次循环自加1也就是加上4个字节的大小,就指向了下一个位置 0x08075240,(*fn_ptr)(); 也就是把该位置的内容取出来也就是相当于 __rt_init_ulog_console_backend_init();。
3 总结 为什么 RT-Thread 要采用这种复杂的方式来进行自动初始化操作呢?我认为是 RT-Thread 采用和 Linux 一样的机制,为了实现驱动和应用的分层将驱动的初始化操作在 main() 函数之前就进行初始化后注册好,等到运行到 main() 函数后,用户只需要关心应用层的额代码即可,如果不采用这种方式而是采用裸机写法的方式在main() 函数的最开始进行初始化,就需要执行很多驱动层的初始化代码,就不能很好的实现驱动和应用的分层,也就不能很好的实现应用层只需关系应用层的逻辑而不用关系驱动和硬件初始化的分层思想了。
|