原理分析:
a、在链接脚本link.lds里定义了专门存放动态符号表的段RTMSymTab。
b、内核对外提供可延时绑定的接口在rtm.h中通过RTM_EXPORT将一对对符号+地址构成的表存放到RTMSymTab段
#define RTM_EXPORT(symbol) const char __rtmsym_##symbol##_name[] SECTION(".rodata.name") = #symbol; ==》 __wrap_"#symbol const struct rt_module_symtab __rtmsym_##symbol SECTION("RTMSymTab")= { (void *)&symbol, __rtmsym_##symbol##_name };
c、方案对比:
(rt-thread原生方案)、编译的时候通过scons --target=ua -s,内核将有延时绑定的接口头文件路径运行放在rtua.py中, app使用的bsp目录下带M_前缀的编译选项。根据编译脚本的配置,都将保存在elf文件中。
缺点1:因为其不能区分哪些接口使用内核的,哪些使用C库的,应用调用的posix接口全部来自内核,这需要内核封装很多C库的接口。也就是C库成为了内核的一部分。
缺点2:不支持连接第三个动态库。
(改进方案)、scons --export生成kernel_export_conf文件,app执行make的时候会将-wrap过的符号自动加上前缀_wrap_
1、通过wrap解决缺点1,使用wrap修饰的接口使用内核,否则使用C库。
2、通过完善dlmoudle模块,支持动态自动查找。
3、通过-shared,将未找到的符号,置0,ndx为UND,其实及时标记延时绑定(elf相关,readelf工具)。
4、通过–e main解决app的入口不一定是main问题。
d、运行的时候dlmodule_load先读取并解析elf文件,将其中需要重定位符号表的重新赋值绑定。
e、创建线程,运行app。
总体说来是:内核通过wrap技术将动态模块中的未定义的符号进行包装,对外导出(export),然后动态模块利用GCC的-shared -fPIC属性生成包含未定义符号的动态库(elf文件),最后在内核中加载动态库并使用elf文件解析器,解析elf文件并将未定义的符号使用内核的导出符号进行重定位。