rt-thread平台 动态装载实现原理

原理分析: a、在连接脚本link.lds里定义了专门存放动态符号表的段RTMSymTab。app

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:不支持链接第三个动态库。spa

c(改进方案)、scons --export生成kernel_export_conf文件,app执行make的时候会将-wrap过的符号自动加上前缀_wrap_    一、经过wrap解决缺点1,使用wrap修饰的接口使用内核,不然使用C库。    二、经过完善dlmoudle模块,支持动态自动查找。    三、经过-shared,将未找到的符号,置0,ndx为UND,其实及时标记延时绑定(elf相关,readelf工具)。    四、经过–e main解决app的入口不必定是main问题。  线程

d、运行的时候dlmodule_load先读取并解析elf文件,将其中须要重定位符号表的从新赋值绑定。 e、建立线程,运行app。code

相关文章
相关标签/搜索