动态模块加载和ELF Loader

很早很早以前就想在嵌入式系统上实现动态模块加载的功能了，期间走了些弯路，直到最近，才完整地在嵌入式系统上实现动态模块加载。

=== 动态模块加载的好处 ===

动态模块加载的好处很多，例如，当你升级一个系统的时候，可以只升级一个模块，而不必升级整个系统。你可以把不同的模块放在不同的介质上，并实施不同等级的保护，例如BIOS部分进行写保护。

有些系统允许用户进行二次开发，这个时候几乎一定是需要动态加载功能的，因为你不希望用户需要链接整个系统才能够进行二次开发，而且你可能希望支持多个用户模块，彼此不相互依赖，彼此不干扰。

=== Background ===

一般来说，C的编译器编译出来的代码，由以下几个重要的部分：
.code: 代码段
.data: 有初值的数据段
.bss： 无初值的数据段

通常还有.rodata，是只读的数据段，在嵌入式系统中经常可以合并到.code段中.

注： .code, .data 和.bss这些段的命名不同的编译器可能会有不同。

由于不同段在实际运行的时候可能会被加载到不同的介质，例如.code和.rodata可以放在NOR FLASH上而.data,.bss放入RAM中，或者要满足所谓的scatter loading，因此编译器会努力使段可以自由移动。

但是要做到这一点，并不容易。

在代码段中运行的指令，要获取数据段中的数据，方法有：
a) 通过当前PC值＋偏移量
b) 通过绝对地址
c) 通过中间寄存器，寄存器里面：
   c.1) 存放绝对地址
   c.2) 偏移量

方法b通常只在CISC中存在，许多RISC机器由于指令长度受限制，并不存在方法b。

因此，从这里可以看出，要做到各段可以自由移动,有几种方法：
1) 保留一个寄存器专门用于指示数据段的起始地址
2) 运行前修改指令
3) 保留一小块数据段和代码段的相对位置不变，此片数据段作为指向实际数据段的入口表， 运行前修改此表。

方法1和方法3通常会结合起来一起用，动态链接库就是用了这种技术。
方发2是一种通用的方法，实际上连接器就是这样生成可执行文件的。

=== ARM AIF ===

ARM公司的编译器有一项特殊的功能，即可以产生一种可自我重定位的可执行文件，即AIF格式。
在AIF文件中，包含了一个AIF头和一小段由编译器产生的重定位代码。运行AIF格式的文件，只需要告诉它起始地址，这段重定位代码就会负责修改余下的一些必要的信息达到重定位目的。目前还没有充分的公开的文档解释AIF内部的详细工作机制。

在我过去的一些项目中，AIF工作的很好，但是运行时外部无法获取AIF文件的更多信息，例如你无法去调用AIF映像中的某一个函数，因为你不知道它的地址。另外，AIF的执行映像中，.data必须紧跟在.code之后，对于想重定位到FLASH中执行的嵌入式系统就行不通了。

=== ELF ===

ELF文件是最常见的目标文件格式，它可能有很多扩展名，例如.o，.so,或者最终的可执行文件也是ELF。

ELF有几种：
* 可重定位
* 可动态链接
* 可执行
* 可执行＋可重定位

可执行的ELF如果没有可重定位信息，那就只能靠虚拟内存系统来支持它运行。但是对于许多嵌入式系统，有可能连MMU都不具备，因此我们只关心可重定位的ELF。（可动态链接ELF实际上也是可重定位的一种，附加很多额外信息）

有关ELF的详细信息，请参阅：http://www.skyfree.org/linux/references/ELF_Format.pdf

=== ELF Loader ===

我花了不少时间寻找小型的ELF Loader实现，但是真正适合嵌入式系统的却不多。

+Contiki OS:
在Contiki OS里面，有一个很有趣的ELF Loader实现，嗯，其实Contiki OS有很多有意思的东西

+ucLinux:
ucLinux也是一个很有意思的例子。由于ucLinux没有启用虚拟内存系统，因此它在加载可执行文件的时候，就要进行重定位。为了加速重定位和减小ELF文件的体积，ucLinux提供了特殊的工具链，在产生ELF之前进行部分的“预重定位”，最后ELF中只需要携带很小体积的重定位信息。

+其它RTOS：
其它嵌入式OS，如VxWorks也实现了ELF Loader, eCos的ELF Loader看起来尚未完整。

+Linux Kernel:
哦，差点忘了一个最重要的，Linux Kernel。

Linux Kernel的模块是可以通过insmod动态地加入内核。虽然Linux的用户空间程序运行在虚拟内存中，整个内核的空间确只有一个。一些奉行micro kernel的人批评Linux的这种方式，但是一个单一空间的内核运行效率却是最高的。

在2.6内核中，模块重定位工作不再由insmod来完成，而是由内核来做所有的重定位工作。实现代码在：kernel/module.c中。

剥去那些处理特殊section的代码，Linux内核模块加载部分的代码其实是非常简单明了的，而且Linux支持数十种架构意味着你几乎不要担心架构移植的问题。

=== 结论 ===

在嵌入式系统中实现动态模块加载的技术是成熟的，可靠的，可以借鉴的开发源码的实现例子也有不少。一个参考数据： 我最近在一个嵌入式RTOS上实现的ELF Loader，运行在ARM7 CPU上，从NAND FLASH中加载一个400K左右的ELF，耗时大约0.5秒。


=== THE END ===

评论

5 楼 ydyd_net 2008-12-07  

您好，我已经实现这个优化了，方法是把函数调用的重定位先处理了，函数调用的相对pc寻址的，加载以后不需要重定位了。对于全局变量，记录需要修改的代码段的地址偏移和将要修改为的值相对运行时首地址的偏移，只需4个字节记住这些信息，在加载后重定位一下，不需要查找符号表，这样很快，而且文件中去掉了代码段和数据段之外的信息，也很小

不知道这样的方式和使用ropi rwpi参数生成出来的代码性能上有什么差别
我用ropi rwpi参数生成出来的文件加载后，重定位r9到数据段首地址，也可以运行

4 楼 ydyd_net 2008-12-01  

您好，怎么查找elf文件中某个函数的地址，并在加载elf的程序中调用
我根据elf文件的符号表查找到了，直接把这个地址付给pc指针，执行就出错
谢谢！

3 楼 ydyd_net 2008-11-28  

您好，谢谢技术分享。
关于unlinux“在产生ELF之前进行部分的“预重定位”，最后ELF中只需要携带很小体积的重定位信息。 ”这部分能和您沟通下了吗，期待您改我发个邮件[e-mail]

目前arm直接生成的可重定位elf文件对我来说太大了

2 楼 bryantwu 2008-10-08  

lz，我最近也实现一个arm elf loader,可以解析ads编译的axf文件，希望能够交流！

1 楼 swimmer2000 2008-06-13  

文章不错，
希望博主有更细致的讲解。