Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

From long time till middle of 2007, We heard BREW doen't support global/static data.(Still few/many brew developers don't know whether they can use global/static data in their applications with the new elf2mod.exe tool or not..)

But with the new elf2mod.exe one can use global/static data in their applications i.e now one can compile their app with -norwpi option.

Can any one explain or post some web links about what exactly this ropi(readonly position independent) and rwpi(read write position independent) is and why one can select -norwpi now and why not earlier.....

The only info I got on this in the forum is posted below..

BenBlaukopf wrote:
Essentially BREW requires position independent code because there is no memory map (the MMU is turned off) and therefore a BREW application may be loaded at any position in RAM.

However, modern toolchains bypass this issue by creating position-dependent code with fixups, and adding a bit of code that is run at startup by the application. This code fixes up all the absolute addresses based upon the current value of the PC (program counter).

ArdyFalls wrote:There is no virtual memory in brew, the application shares the same memory 'file' with the OS. This means that bad pointers, etc can overwrite parts of the OS.

The way brew deals with memory is that your mod file is separated into three sections. The RO section, the RW section and the ZI section. The RO (Read Only) section is where all your code goes, the RW (Read-Write) section is where all your globals and statics go, the ZI section is where all 'zero' initialized data goes. Now, why you can't use globals and statics when using the ARM compiler is because probably you are compiling to a BIN file. A BIN file is pure compiled code, essentially the RO section of the mod. Now with other compilers like win-arm-gcc, you can provide linker scripts that will allow you to segment your mod file such that you have all your code in the RO section, all your globals in the RW section, etc...

Now, what fixup tools like elf2mod do is as follows, they at run time trap the address in memory where the application was loaded. Then they take this address and store it in either a register or they update all the references to a particular address to be that address + the address that the application was loaded at. I'm not entirely sure exactly how elf2mod works but I;m sure its one of the two mentioned ways.

I hope this helps.

ruben wrote:In addtion to the lack of MMU support, because MMU costs more, ARM chipset provides hook, but OEM doesn't provide it and BREW doesn't provide support for virtual memory.

The actual issue with BREW is that, the BREW's internal binary loader is really simple that is , it loads your binary into the memory using file read and then jumps to the first address and starts executing.

In advanced system like Win32, dll loaders are much more involved, when there is address collision it would adjust (that's how when crash happens in Win32 you can use the crash offset and map file and find out the crash location) and load address, but BREW loaders are not that fancy. On top of that BREW loaders doesn't do any scatter image loading that would support text segment, data segment and bss segment. It just loads the text segment, that's why in the BREW image you would see on code segment.

Thanks for ArdyFalls,BenBlaukopf and ruben for their contribution on this topic. :) :) :)

thanks for summarizing and posting it here.

thanks for summarizing and posting it here.

Thanks Brewin,
its really good info u pasted here:)

Thanks Brewin,
its really good info u pasted here:)

Thanks for the compiled information..
looking forward for more insight on the same
Thanks

Thanks for the compiled information..
looking forward for more insight on the same
Thanks