Using static variables in classes... | developer.brewmp.com Using static variables in classes... | developer.brewmp.com

Developer

Using static variables in classes...

When we adding some static variables into class, we have to init them:

class a{
static int istatic;

public:
static void seti( int i){
istatic = i;
}
;

// and init istatic with default value:
a::istatic = 0;

But! There are problems with compiling this code with rvct 2.2...

...in PI region 'ER_RO' cannot have address type relocation to .data$0 in PI region 'ER_RW'.

Maybe, rvct doesn't support static vars? - But, I believe, it has to...

I haven't tried this but Nathan posted an annoucement regarding the new elf2mod tool. According to him, we don't have to use the 'ropi' and 'rwpi' flags with the new elf2mod. Maybe we can start migrating... Here is the link to the post: http://brewforums.qualcomm.com/showthread.php?t=12804
HTH

I haven't tried this but Nathan posted an annoucement regarding the new elf2mod tool. According to him, we don't have to use the 'ropi' and 'rwpi' flags with the new elf2mod. Maybe we can start migrating... Here is the link to the post: http://brewforums.qualcomm.com/showthread.php?t=12804
HTH

elf2mod should work. This looks like a pretty cut-and-dried case of static variables. Static variables, rwpi, and BREW just don't go together.

elf2mod should work. This looks like a pretty cut-and-dried case of static variables. Static variables, rwpi, and BREW just don't go together.

Hi,
I modified a working makefile by removing all refs to -ropi and -rwpi etc, but when I try to convert the elf using the new Elf2mod release I get the following error:
elf2mod: Error: BrewMod:43: ELF2Mod_Exception : ELF file not suitable for conversion to a BREW module
Does anyone know what changes need to be made to the standard makefile (the one the ARM makefile generator spits out) to get this to work?
I've tried a bunch of things, but nothing worked. The changes I've tried either cause linker problems, or produce an elf that elf2mod refuses to convert.
Any help greatly appreciated...
-Murderizer

Hi,
I modified a working makefile by removing all refs to -ropi and -rwpi etc, but when I try to convert the elf using the new Elf2mod release I get the following error:
elf2mod: Error: BrewMod:43: ELF2Mod_Exception : ELF file not suitable for conversion to a BREW module
Does anyone know what changes need to be made to the standard makefile (the one the ARM makefile generator spits out) to get this to work?
I've tried a bunch of things, but nothing worked. The changes I've tried either cause linker problems, or produce an elf that elf2mod refuses to convert.
Any help greatly appreciated...
-Murderizer

This is first,
next, u have to add --reloc --split to your linker...
good luck...
As for me, this is a time when quallcom have to give some humanistic tools to develop applications...

This is first,
next, u have to add --reloc --split to your linker...
good luck...
As for me, this is a time when quallcom have to give some humanistic tools to develop applications...

The version of Elf2mod I'm using is the latest release (v1.0.2.02), released 7 July 2006. I confirmed on the commandline that it is infact the correct version of Elf2mod, although I've never installed any previous versions.
I added the switches you mentioned above. Everything compiles and links fine, as before, but I still get the same error message from Elf2mod:
elf2mod: Error: BrewMod:43: ELF2Mod_Exception : ELF file not suitable for conversion to a BREW module
Within the makefile there are two areas where -ropi etc are used, the compiler flags (APCS specifically) and the linker flags (LFLAGS).
The linker flags are set as follows:
LFLAGS = -reloc -split -entry 0x8000#
The compiler flags are set as follows:
APCS = -apcs /$(ROPI)/$(INTERWRK)/norwpi
I've tried changing norwpi to rwpi, and even removing it but no joy. ROPI is defined as simply ropi, and that is the default and only option according to the compiler docs, although I have tried removing both ROPI and norwpi - it still doesn't work.
I'm at a loss...is there something else that needs to be changed / added?
-Murderizer

The version of Elf2mod I'm using is the latest release (v1.0.2.02), released 7 July 2006. I confirmed on the commandline that it is infact the correct version of Elf2mod, although I've never installed any previous versions.
I added the switches you mentioned above. Everything compiles and links fine, as before, but I still get the same error message from Elf2mod:
elf2mod: Error: BrewMod:43: ELF2Mod_Exception : ELF file not suitable for conversion to a BREW module
Within the makefile there are two areas where -ropi etc are used, the compiler flags (APCS specifically) and the linker flags (LFLAGS).
The linker flags are set as follows:
LFLAGS = -reloc -split -entry 0x8000#
The compiler flags are set as follows:
APCS = -apcs /$(ROPI)/$(INTERWRK)/norwpi
I've tried changing norwpi to rwpi, and even removing it but no joy. ROPI is defined as simply ropi, and that is the default and only option according to the compiler docs, although I have tried removing both ROPI and norwpi - it still doesn't work.
I'm at a loss...is there something else that needs to be changed / added?
-Murderizer

...and which version of brew?

...and which version of brew?

I'm using RVCT v1.2 compiled against Brew 2.1. Is it the case that RVCT 1.2 just doesn't work here?
Here's a bit more info on the code I'm compiling: It's made up of c (ARM) and c++ (Thumb) code. It makes use of static const class members, virtual class methods and compiles, links and converts to .mod (using elf2mod) provided I don't add a regular read/write global variable.
Thanks in advance.

I'm using RVCT v1.2 compiled against Brew 2.1. Is it the case that RVCT 1.2 just doesn't work here?
Here's a bit more info on the code I'm compiling: It's made up of c (ARM) and c++ (Thumb) code. It makes use of static const class members, virtual class methods and compiles, links and converts to .mod (using elf2mod) provided I don't add a regular read/write global variable.
Thanks in advance.

Just a quick update for anyone else having similar problems. The problem was with the linker '-entry' setting:
previously I had:
LFLAGS = -reloc -split -entry 0x8000
but this needs to be:
LFLAGS = -split -reloc -entry AEEMod_Load
I stumbled onto this while reading a different post on how to get winARM working. The app compiles, links, converts to mod and runs fine on a handset, and the code contains proper global variables.
I'm going to test this quite a bit to make sure it's completely stable. If I have any problems I'll post them here.

Just a quick update for anyone else having similar problems. The problem was with the linker '-entry' setting:
previously I had:
LFLAGS = -reloc -split -entry 0x8000
but this needs to be:
LFLAGS = -split -reloc -entry AEEMod_Load
I stumbled onto this while reading a different post on how to get winARM working. The app compiles, links, converts to mod and runs fine on a handset, and the code contains proper global variables.
I'm going to test this quite a bit to make sure it's completely stable. If I have any problems I'll post them here.

Just a warning to anyone developing an application with multiple class Ids (in the MIF): the globals of the first instance of the application are not stored in a unique memory context and will therefore be overwritten with the launching of the second instance (hence, trashing the first instance).

Just a warning to anyone developing an application with multiple class Ids (in the MIF): the globals of the first instance of the application are not stored in a unique memory context and will therefore be overwritten with the launching of the second instance (hence, trashing the first instance).

Up until now I've been using simple Static members and my tests have all worked out well. I'm working with RVCT 1.2, but the points below probably apply to the GNU tool chain too.
There is another gotcha's in addition to the one Particleman pointed out above.
1: The new Elf2mod does not deal with non-POD globals/static members correctly - in other words it doesn't call a constructor off a global class instantiation. It should be possible for Elf2mod to do this so hopefully this can be addressed in a future release - Qualcomm, any chance of this? Lightblue's Elf2mod replacement does deal with this, but their tool only works with code from RVCT 2.2. The requirement for RVCT 2.2 is to do with virtual method calls though, not non-POD initialisation.
[Edit: I had previously reported that there was a problem with static members being spread amound classes in a hierarchy, and across files, but I have since confirmed there was another problem in my build causing this. My current app does not present this problem]
In case anyone from Qualcomm is reading this: I'm sure you realise this but supporting globals/static members correctly, and fully is quite a significant boost to Brew. We all know the standard coding mantra "globals are bad" etc etc, but the fact is having globals significantly reduces the amount of effort required to port existing code into Brew, especially from langauges like J2me, where it is advantageous to engineer code using static members / methods for jar size reasons etc. Increasingly I'm seeing porting projects from PC codebases (and even consoles!!), especially with respect to 3D apps. Having full support for globals (non-POD and POD) is going to be quite a big deal as app size and complexity goes up. I look forward to future releases of Elf2mod!

Up until now I've been using simple Static members and my tests have all worked out well. I'm working with RVCT 1.2, but the points below probably apply to the GNU tool chain too.
There is another gotcha's in addition to the one Particleman pointed out above.
1: The new Elf2mod does not deal with non-POD globals/static members correctly - in other words it doesn't call a constructor off a global class instantiation. It should be possible for Elf2mod to do this so hopefully this can be addressed in a future release - Qualcomm, any chance of this? Lightblue's Elf2mod replacement does deal with this, but their tool only works with code from RVCT 2.2. The requirement for RVCT 2.2 is to do with virtual method calls though, not non-POD initialisation.
[Edit: I had previously reported that there was a problem with static members being spread amound classes in a hierarchy, and across files, but I have since confirmed there was another problem in my build causing this. My current app does not present this problem]
In case anyone from Qualcomm is reading this: I'm sure you realise this but supporting globals/static members correctly, and fully is quite a significant boost to Brew. We all know the standard coding mantra "globals are bad" etc etc, but the fact is having globals significantly reduces the amount of effort required to port existing code into Brew, especially from langauges like J2me, where it is advantageous to engineer code using static members / methods for jar size reasons etc. Increasingly I'm seeing porting projects from PC codebases (and even consoles!!), especially with respect to 3D apps. Having full support for globals (non-POD and POD) is going to be quite a big deal as app size and complexity goes up. I look forward to future releases of Elf2mod!

Further tests to the ones carried out above revealed the following:
Having globals or not made no difference. The crashes on app exit (which happened roughly 90% of the time) continued to happen. This implied that the problem resides in the new release of elf2mod.
To test this I returned my build process back to the usual, no-globals, fromelf.exe process. Sure enough the build works fine when converted to Mod using fromelf, but crashes when converted using the new elf2mod. This build has no globals, statics etc and is built using the following:
c files: armcc
-Wx -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -zo -fa -fy -Ospace -O2 " + $(U_BREW_ARM_ENDIAN) + " " + $(U_BREW_ARM_DEBUG) + " " + $(U_BREW_ARM_INC_DIRS) + " " + $(U_BREW_C_FILENAMES)
cpp files: armcpp
"-Wx -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -zo -fa -fy -Ospace -O2 " + $(U_BREW_ARM_ENDIAN) + " " + $(U_BREW_ARM_DEBUG) + " " + $(U_BREW_ARM_INC_DIRS) + " " + $(U_BREW_CPP_FILENAMES)
linker: armlink
"-o testapp.elf -ropi -rwpi -rw-base 0 -ro-base 0 -entry AEEMod_Load " + [Object files here]+ " -first AEEMod_Load"
convert to mod: fromelf
"-output testapp.mod -bin testapp.elf"
Note- the above params for compilation and linkage are straight from the Qualcomm makefiles.
One possible reason elf2mod is messing up is because I'm using Templates quite a bit - they're a critical part of our internal middleware. I'm currently looking into this.

Further tests to the ones carried out above revealed the following:
Having globals or not made no difference. The crashes on app exit (which happened roughly 90% of the time) continued to happen. This implied that the problem resides in the new release of elf2mod.
To test this I returned my build process back to the usual, no-globals, fromelf.exe process. Sure enough the build works fine when converted to Mod using fromelf, but crashes when converted using the new elf2mod. This build has no globals, statics etc and is built using the following:
c files: armcc
-Wx -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -zo -fa -fy -Ospace -O2 " + $(U_BREW_ARM_ENDIAN) + " " + $(U_BREW_ARM_DEBUG) + " " + $(U_BREW_ARM_INC_DIRS) + " " + $(U_BREW_C_FILENAMES)
cpp files: armcpp
"-Wx -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -zo -fa -fy -Ospace -O2 " + $(U_BREW_ARM_ENDIAN) + " " + $(U_BREW_ARM_DEBUG) + " " + $(U_BREW_ARM_INC_DIRS) + " " + $(U_BREW_CPP_FILENAMES)
linker: armlink
"-o testapp.elf -ropi -rwpi -rw-base 0 -ro-base 0 -entry AEEMod_Load " + [Object files here]+ " -first AEEMod_Load"
convert to mod: fromelf
"-output testapp.mod -bin testapp.elf"
Note- the above params for compilation and linkage are straight from the Qualcomm makefiles.
One possible reason elf2mod is messing up is because I'm using Templates quite a bit - they're a critical part of our internal middleware. I'm currently looking into this.

Rock Lee wrote:I haven't tried this but Nathan posted an annoucement regarding the new elf2mod tool. According to him, we don't have to use the 'ropi' and 'rwpi' flags with the new elf2mod. Maybe we can start migrating... Here is the link to the post: http://brewforums.qualcomm.com/showthread.php?t=12804
HTH
Tried and work

Rock Lee wrote:I haven't tried this but Nathan posted an annoucement regarding the new elf2mod tool. According to him, we don't have to use the 'ropi' and 'rwpi' flags with the new elf2mod. Maybe we can start migrating... Here is the link to the post: http://brewforums.qualcomm.com/showthread.php?t=12804
HTH
Tried and work