一篇写的很好的关于ARM动态加载的文章.doc

动态模块加载和ELF Loader文章分类:IT生活 关键字: embedded elf 动态模块加载很早很早以前就想在 HYPERLINK / \t _blank 嵌入式系统上实现动态模块加载的功能了，期间走了些弯路，直到最近，才完整地在嵌入式系统上实现动态模块加载。=== 动态模块加载的好处 ===动态模块加载的好处很多，例如，当你升级一个系统的时候，可以只升级一个模块，而不必升级整个系统。你可以把不同的模块放在不同的介质上，并实施不同等级的保护，例如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的详细信息，请参阅： HYPERLINK /linux/references/ELF_Format.pdf \t _blank /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:哦，差点忘了一个最重要的，Li