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

Developer

Forums

Forums:

This is not cool... it still seems like SOMETHING is running into my global/static section. I have nearly no static variables (though plenty of static functions) but something is running in to them. Even though variables are being initialized to null (static variables that is) they are ending up with values in them.

SOmething with when it compiles is throwing either garbage or code into the wrong section i think, but I have no idea how to fix it. Has anyone else run in to this problem? If so does anyone know how to fix it? We do all our compilation with the ADS 1.2 compiler.

KAJed wrote:This is not cool... it still seems like SOMETHING is running into my global/static section. I have nearly no static variables (though plenty of static functions) but something is running in to them. Even though variables are being initialized to null (static variables that is) they are ending up with values in them.
SOmething with when it compiles is throwing either garbage or code into the wrong section i think, but I have no idea how to fix it. Has anyone else run in to this problem? If so does anyone know how to fix it? We do all our compilation with the ADS 1.2 compiler.
Trust me, you are trashing memory somewhere. You will first need to reliably reproduce the problem, then start walking back and check each points to see if the variables are what they are.
Memory trashing is always difficult to fix. You may need a fresh pair of eyes to check the code.
I do feel your pain ;)

KAJed wrote:This is not cool... it still seems like SOMETHING is running into my global/static section. I have nearly no static variables (though plenty of static functions) but something is running in to them. Even though variables are being initialized to null (static variables that is) they are ending up with values in them.
SOmething with when it compiles is throwing either garbage or code into the wrong section i think, but I have no idea how to fix it. Has anyone else run in to this problem? If so does anyone know how to fix it? We do all our compilation with the ADS 1.2 compiler.
Trust me, you are trashing memory somewhere. You will first need to reliably reproduce the problem, then start walking back and check each points to see if the variables are what they are.
Memory trashing is always difficult to fix. You may need a fresh pair of eyes to check the code.
I do feel your pain ;)

I'm no stranger to that type of bug... however.... at the very beginning of the application (ie: the first line of the AEECreateInstance) variables that were set to NULL are not set to NULL. The only way I could get earlier would be to put code inside of the AEEModLoad function before the vtables for IApplet are created. At this point there are 0 allocations made by me.

I'm no stranger to that type of bug... however.... at the very beginning of the application (ie: the first line of the AEECreateInstance) variables that were set to NULL are not set to NULL. The only way I could get earlier would be to put code inside of the AEEModLoad function before the vtables for IApplet are created. At this point there are 0 allocations made by me.

You said you have static variables in your code. I would imagine you are compiling your code without ROPI flag and then passing via ELF2MOD tool. Static functions doesn't require any fixups.
Are you seeing this in emulator or device? Is it happenning by the time you get AEEClsCreateInstance or before that (like AEEModLoad)?

You said you have static variables in your code. I would imagine you are compiling your code without ROPI flag and then passing via ELF2MOD tool. Static functions doesn't require any fixups.
Are you seeing this in emulator or device? Is it happenning by the time you get AEEClsCreateInstance or before that (like AEEModLoad)?

I am linking with armlink with the -ropi flag.
I am ONLY seeing these problems on the device. The emulator actually works perfect. I haven't seen a memory corruption at all in the emu.
Currently I am only checking the status of the particular variable (I know exactly which one fails every time at this point) and it is returning a value of 0x00000008 even though its definition is:
Game* EC::game = NULL;
We are indeed using the elf2mod tool to generate a mod file.
I haven't been able to test the value of the variable before AEEMod_Load happens due to some strange compile issues at the moment that I'm trying to fix (c vs c++ compiling)

I am linking with armlink with the -ropi flag.
I am ONLY seeing these problems on the device. The emulator actually works perfect. I haven't seen a memory corruption at all in the emu.
Currently I am only checking the status of the particular variable (I know exactly which one fails every time at this point) and it is returning a value of 0x00000008 even though its definition is:
Game* EC::game = NULL;
We are indeed using the elf2mod tool to generate a mod file.
I haven't been able to test the value of the variable before AEEMod_Load happens due to some strange compile issues at the moment that I'm trying to fix (c vs c++ compiling)

If it helps I had this problem before but I solved it by removing like 80% of our static data and making them parts of allocated objects. Which led me to believe that the RW section was running into something or the RO section running in to the RW section. Unfortunately I don't know much about code sections except that elf2mod doesn't have any way for me to check on them.

If it helps I had this problem before but I solved it by removing like 80% of our static data and making them parts of allocated objects. Which led me to believe that the RW section was running into something or the RO section running in to the RW section. Unfortunately I don't know much about code sections except that elf2mod doesn't have any way for me to check on them.

The output of elf2mod is:
elf2mod: RelocMod ro-base=0x200 rw-base=0x2aaa0
I am checking 2 of my statics ,
Game* EC::game = NULL;
and Game* Game::instance = NULL;
Technically these will eventually point to the same thing but at the beginning of my application their values are:
0x00028cdc and 0x00028ce0
respectively. So even though they were nulled that is their values. However, I noticed that those values would point them towards the RO section... and that would be problematic, though I'm not sure how they got those values to begin with.

The output of elf2mod is:
elf2mod: RelocMod ro-base=0x200 rw-base=0x2aaa0
I am checking 2 of my statics ,
Game* EC::game = NULL;
and Game* Game::instance = NULL;
Technically these will eventually point to the same thing but at the beginning of my application their values are:
0x00028cdc and 0x00028ce0
respectively. So even though they were nulled that is their values. However, I noticed that those values would point them towards the RO section... and that would be problematic, though I'm not sure how they got those values to begin with.

.... Changing my link order makes SOME things work.... that's not good right?

.... Changing my link order makes SOME things work.... that's not good right?

KAJed wrote:.... Changing my link order makes SOME things work.... that's not good right?
What does your AEEApplet look like? You've got a C++ class deriving from AEEApplet? Keep in mind that you cannot have any virtual function or constructor/destructor in the class that derives from AEEApplet.

KAJed wrote:.... Changing my link order makes SOME things work.... that's not good right?
What does your AEEApplet look like? You've got a C++ class deriving from AEEApplet? Keep in mind that you cannot have any virtual function or constructor/destructor in the class that derives from AEEApplet.

No sir.... we used to do that, now I simply use the AEEApplet as is with no subclassing.

No sir.... we used to do that, now I simply use the AEEApplet as is with no subclassing.

I've done a lot of work with this problem and still the only solution is reordering the objects to the linker. It is our suspicion that there is a limit currently with elf2mod on the amount of static data and also where it is grouped. Unfortunately my guess is that elf2mod nor armlink does any work at grouping all the statics in to the same area once compiled, since moving a class with statics to the beginning of the link link causes those statics to work again.
Obviously defining a "working" link list for every project is a little silly so hopefully Qualcomm will take a look at this and fix it.

I've done a lot of work with this problem and still the only solution is reordering the objects to the linker. It is our suspicion that there is a limit currently with elf2mod on the amount of static data and also where it is grouped. Unfortunately my guess is that elf2mod nor armlink does any work at grouping all the statics in to the same area once compiled, since moving a class with statics to the beginning of the link link causes those statics to work again.
Obviously defining a "working" link list for every project is a little silly so hopefully Qualcomm will take a look at this and fix it.