|
Tigris.org
Open Source Software Engineering Tools
|
|
|
IntroductionThe lightblue mod generateor (lbmg.exe) is a post linker that create self relocated MOD files from ELF files. Besides the full support of lightblue C++ wrapper library's direct memory mapping scheme, it also support many language features that are missing from the current ARM compiler when "read only position independent" (ropi) is on. These features include:
Why it is neededThe BREW platform requires the MOD file be position independent (ropi), so that it could be loaded into any adrress and executed without relocation. The ARM compiler (ADS 1.2 or Realview 2.x) will use pc related addressing mode when the -ropi flag is on , which works very well on most C programs provided that they don't use any global or static variables; all addresses are stored as an offset to the current pc register instead of an aboslute address.However, when C++ language is used, one of the most fundamental feature of C++, aka virtual function ,cannot be implemented properly by this way. By the C++ ABI, virtual functions are implemented using v-table ( virtual function table) which is an array of aboslute address to all the virtual functions in the class. Since -ropi prohibits absolute addresses in the executable, the v-table functionality cannot be implemented without breaking the C++ ABI. In this case, the ADS 1.2 (the old ARM compiler) and the Realview 2.x (the new ARM compiler) use completely different approaches. The Realview 2.x compiler, which is strickly ARM C++ ABI compliant and , as stated on its document, will not support virtual functions when the -ropi is on. The ADS 1.2 compiler, on the other hand, chooses to break the C++ ABI by storing offsets in the v-table instead of absolute addresses. The consequences of this is that the virtual function call becomes a more costly operation, both in speed and space, than the standard implementation. It will add an extra 4 CPU circles and 16 extra bytes to every virtual function call compare to non-virtual function call while the standard implementation will only cost 3 CPU circles and 12 extra bytes. In one words, function functions in ADS 1.2 is slow and make your final MOD file bigger. Check this article C++ Idioms in BREW: Better Interfaces on www.developer.com. The author claimed that a pattern called "static interface" will boost the speed up to 30% comparing to C++ virtual functions. I guess the code must be compiled by the ADS 1.2 compiler, the only ARM compiler at that time. The other consequence of ADS1.2's implementation of virtual functions is that it is not compatible with the lightblue C++ Class Wrapper library which requires that the compiler's virtual function implementation must be complaint with the standard ARM C++ ABI. Therefore, the ADS 1.2 compiler is not supported by the lightblue C++ Class wrapper library. The lightblue team decided to work on the Realview 2.x compiler because of its ARM C++ ABI compliant. The solution is to create a self relocatable MOD files out of the ELF file gnerated by the compiler. A small startup code, which is around 140 bytes in size, is appended to the MOD file which adjust all absolute addresses to the correct value depending on the base address the MOD file is loaded to. The result is that Realview 2.x compiler becomes the best compiler that supports the lightblue C++ Class Wrapper library which generates faster and smaller code than the ADS 1.2 compiler. NOTES: The lightblue C++ Class Wrapper library also supportes the GNU ARM compiler, but it is done by the post linker (BREWelf2mod.exe) provided by Qualcomm. In the future versions, the lbmg.exe will also support GNU ARM compiler as well. Supported Compilers
|
|||||||||||||||||||||||||||||
