read only position independent code | developer.brewmp.com read only position independent code | developer.brewmp.com

Developer

read only position independent code

Forums:

Hi all,

We have an ROPI option in ARM compiler. and I understand only brew uses this option. Is there any other platform that uses -ROPI option. and why do brew needs ROPI code.

Thanks in Advance,
KUmar

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).
You should check out Elf2Mod.exe
https://brewx.qualcomm.com/brew/sdk/authdownload.jsp?page=dx/elf2mod

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).
You should check out Elf2Mod.exe
https://brewx.qualcomm.com/brew/sdk/authdownload.jsp?page=dx/elf2mod

thanks, that was really informative :)

thanks, that was really informative :)

Thanks a lot BenBlaukopf . This will be very helpful to me :)

Thanks a lot BenBlaukopf . This will be very helpful to me :)

Hi BenBlaukopf,
Could you please give me links for " how brew deals with memory ?"
How virtual memory management happens for brew if there is no MMU?
Thanks a lot for your help!!
Best Regards,
Kumar

Hi BenBlaukopf,
Could you please give me links for " how brew deals with memory ?"
How virtual memory management happens for brew if there is no MMU?
Thanks a lot for your help!!
Best Regards,
Kumar

BenBlaukopf,
The link which you gave for elf2mod not opening :(

BenBlaukopf,
The link which you gave for elf2mod not opening :(

pskumar wrote:BenBlaukopf,
The link which you gave for elf2mod not opening :(
Hi,
It is indeed working..You need to be an authenticated BREW Developer to access the link.. :)

pskumar wrote:BenBlaukopf,
The link which you gave for elf2mod not opening :(
Hi,
It is indeed working..You need to be an authenticated BREW Developer to access the link.. :)

The link is correct - I just checked it. But you need to be a registered developer with a login.

The link is correct - I just checked it. But you need to be a registered developer with a login.

BenBlaukopf and ocean eleven,
Thanks for your replies.
Could you please give me links for " how brew deals with memory ?"
How virtual memory management happens for brew if there is no MMU?
Thanks a lot for your help!!
Best Regards,
Kumar

BenBlaukopf and ocean eleven,
Thanks for your replies.
Could you please give me links for " how brew deals with memory ?"
How virtual memory management happens for brew if there is no MMU?
Thanks a lot for your help!!
Best Regards,
Kumar

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 liker 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.

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 liker 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.

Thanks for that detailed explanation Ardy :) :) :)

Thanks for that detailed explanation Ardy :) :) :)

Thanks a lot Ardy. I got some idea on brew memory organization now.
Could you pls give me links for any reference documents which explains this flow.
Thanks you once again.
Best Regards,
Kumar

Thanks a lot Ardy. I got some idea on brew memory organization now.
Could you pls give me links for any reference documents which explains this flow.
Thanks you once again.
Best Regards,
Kumar

You should look at the document that come along with the elf2mod tool.
https://brewx.qualcomm.com/brew/sdk...page=dx/elf2mod

You should look at the document that come along with the elf2mod tool.
https://brewx.qualcomm.com/brew/sdk...page=dx/elf2mod

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.

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.