brew动态模块文件格式发展浅析：From MOD to MOD1.docVIP

毛晓冬 2010 10 10为什么在BMP中开始引入MOD1格式，并且同时支持MOD和MOD1两种格式那？ 这还得从最初的MOD格式开始说起。话说，最初时，BREW利用MOD这种格式作为动态模块加载的文件格式。 其实， MOD文件是纯的可执行文件，除了RO DATA， RO Code Section以外，不再包含任何的非可执行的数据，如符号表等。 MOD是从ELF转换而来的，剔除冗余的数据后，就变成了一个纯的可执行文件 MOD。由于是纯的可执行文件，所以，理论上当MOD被加载后，PC跳转到加载的RAM的起始地址执行即可。 当然，这里需要解决几个问题。1. 由于是纯的可执行文件格式，加载时，BREW不会负责从额外的信息中提取入口函数地址，即 Entry Point， BREW仅仅是简单的跳转至MOD加载后的RAM起始地址（严格意义上说，这里需要偏移一个AEESTDLIB的 pvt指针，即4个字节）。 所以，我们的MOD Link时，必须要求其Entry Point（AEE_MOD_Load）被Link在最开始的位置，即 First order。2. 另外，由于MOD是在运行时按需加载，所以会加载到任意的地址。 那么，就必须要求MOD是PI的，即Position Independent， 加载至任何地址都可以运行。 通常PI包含两种， ROPI 和 RWPI。 ROPI（只读位置无关）可以不依赖于运行平台而单独由编译期编译时实现，通常的实现方式为基于PC相对寻址即可。 而RWPI（读写位置无关），通常情况下需要运行平台的支持，需要在运行时进行重定向，否则加载时的RW域地址和运行时域地址不一致，会导致Crash。 由于BREW不依赖于底层平台，所以最初的BREW要求MOD必须是ROPI的。OK， 告一段落， 上面的两个问题，在最初的MOD中很好的解决了， 在BREW1.0，2.0，3.0都运行的不错， 当时的BREW全部运行与一个Process中，所以，MOD只会被加载一次，此后，整个Process中的BREW全部共享该 in-Memory MOD时间发展到BREW3.1左右（可能有偏差，应该差不多）。越来越多的呼声要求BREW的Mod中可以使用RW，即全局或者静态变量。 大家知道，当BREW平台不进行更改时，RW数据是不可能在运行时被BREW进行重定向的，所以，依靠BREW平台本身，是不可能支持MOD中包含RW数据的。 那怎么办？！ 后来，一个讨巧的办法找到了，就是在MOD中做文章，即利用ELF2MOD工具， 当Build出ＥＬＦ后，利用该工具转换成Ｍｏｄ文件，那么就可以支持ＲＷ数据了，　其基本原理是，将ＥＬＦ中的ＲＷ段的重定向信息以ｔａｂｌｅ的形式加到Ｍｏｄ文件的头部， AEEMOD_Load位置顺移。 BREW平台的加载机制仍然没用变化，当然，此时加载后跳转到的入口地址不是AEEMod_Load了，而是一段小型的重定向程序，由其读取重定向table后进行RW的运行时重定向，然后再跳转到AEEMod_Load如此一来， BREW动态应用中也可以使用全局/静态数据了，而且据我所知，很多的Developer确实这么做了，但是，其带来的很现实的问题也不容小觑。 大的软件思想方面的耦合变紧且不谈，具体的至少有下面两点：1. ELF2MOD生成的Mod中如果包含RW，那么动态的方式运行没有问题，一旦编成ConstFile Link到Handset的Image中，运行时就会Crash，这是由于，Mod一旦变成ConstFile后，就是ReadOnly了，这是操作系统层次保护的，那么当运行时，对RO段进行写（重定向MOD中的RW）操作，肯定就Crash了。2. 多应用共享一个In Memory MOD时，如果该MOD中使用了全局/静态数据，而该全局/静态数据为一全局/静态指针，并指向了一段运行时分配的内存，而该内存却在应用的环境下分配，那么，当第一个应用退出后，该内存会被BREW自动释放，那么，这个全局的指针就变成了野指针了。 诸如此类的问题，应该还有很多。但是，不管怎么样，在BMP出来之前，这样的现状一直持续着。OK， 新纪元来临了， BMP的到来使得动态模块的文件格式有机会彻底改革一下。 如何改革那？1. 首先， 对于MOD， 不能去除。 必须兼容它， 并兼容它的行为。 因为任何事物我们都应该慢慢的演进，并存，而不应该以激进的方式。毕竟遗留的Mod Style的代码和设计理念还是大量存在。2. OK，保留Mod，且兼容它的行为，所以， 仍然保证一个Process内完全共享一个in memory MOD，而不管它是否包含RW。3. 由于BMP支持多Process，那么，