#21915 - johnny_north - Wed Jun 09, 2004 3:40 pm
I?m having the darndest problem and I?m not sure of how many of the circumstances are pertinent, but here goes:
| Code: |
#include ?gba.h?
#include ?console.h?
Console console;
int main(){
console.start();
return 0;
} |
The whole game runs fine like this. However, if I comment out both the declaration of console and comment out console.start(), but link console.o to the project ? the binary hangs. I seem to find that one of console.cpp dependency files - background.o appears to be the offending object file. Nearly all of the code and data object files can be linked to produce a working rom, but the addition of background.o to the list of .o files to link causes the rom to hang immediately after starting.
If I strip out all of the code except for externs, declarations and includes from background.cpp and link background.o the rom works fine ? so It?s got to be a quirk with the code in this file ? right?
I?m hoping that someone?s conquered a similar problem and can help me cut down what?s looking like a lengthy bug hunt (the code in this file spans nearly 2000 lines and roughly half of it is interdependent). Any ideas?
#21916 - poslundc - Wed Jun 09, 2004 3:59 pm
I'm not sure I understand why your console object would automatically launch in the first place.
Dan.
#21917 - johnny_north - Wed Jun 09, 2004 4:15 pm
| Quote: |
| I'm not sure I understand why your console object would automatically launch in the first place. |
If I understand you correctly, my answer is that it shouldn't do anything until I call one of console's member functions. However, normally that's the first thing I would do inside main().[/quote]
#21919 - Abscissa - Wed Jun 09, 2004 5:00 pm
That does seem odd. I do know that crt0.o (If you're using that one) needs to be the first object file passed to the linker otherwise the ROM won't work. Is it possible that that your inclusion/exclusion of those things is causing your makefile to pass the object files to the linker in a different order?
Some shots in the dark: Maybe there's something weird with a constructor or global either expecting an instance of Console to exist? Maybe Console's constructor does something that another constructor or global expects to have been done? Or maybe some sort of memory error in something's constructor/destructor.
If it's a problem in the code, I'd think it would have to be a constructor or a destructor, otherwise it'd probably be a problem in the build process.
#21924 - johnny_north - Wed Jun 09, 2004 5:27 pm
| Quote: |
| Is it possible that that your inclusion/exclusion of those things is causing your makefile to pass the object files to the linker in a different order? |
The linker output is correct. The .map file shows that the member functions of background.cpp all reside in rom after ctr0 and main's functions (there are no directives to place any of background.cpp's functions anywhere else).
The strangest behavior is that if all the .o files (including background.o) are linked and console is declared - the game runs fine.
However, if all the .o files are linked and console is not declared the rom hangs immediately.
Edit - either I didn't all of your post or you added to it.
The real problem appears to be linking with background.o. If I remove console.o and any refs to it in main, the the rom works as expected so long as background.o has not been linked.
#21925 - johnny_north - Wed Jun 09, 2004 5:55 pm
Ok, all functions from background.cpp that are not needed by other functions in this file are now gone including the costructor and any inline assembly. background.o still causes the rom to hang. I'm going to start removing the code from all of the other function bodies - one at a time until I pinpoint the problem code.
I pray that the problem is in the first few functions. ;(
#21926 - sajiimori - Wed Jun 09, 2004 6:07 pm
You aren't creating a big static array that's filling up IWRAM, right?
#21929 - johnny_north - Wed Jun 09, 2004 6:21 pm
| Quote: |
| You aren't creating a big static array that's filling up IWRAM, right? |
Right - no static variables are used in any of background.cpp's functions.
#21931 - sajiimori - Wed Jun 09, 2004 7:19 pm
I mean "static" in the more general sense of memory that's allocated before main() executes. That includes these:
| Code: |
int a;
static int b;
void f() { static int c; }
class X { static int d; }; int X::d;
|
#21933 - johnny_north - Wed Jun 09, 2004 8:02 pm
Gotcha-
No, I'm not using static like this in background.cpp. I did choose to use static const declarations in lieu of some #defines where it seemed to be appropriate to do so (within the class definition).
I haven't had need to use static in the manner you suggest. In your example:
a is an integer with global scope
b is an integer with file scope
c is an integer whose data persists and has f() scope
d is an integer that will be shared amongst all instances of X
int X::d - I think this is the correct way to intialize d
Just quizzing my self to see if I understand the concept, although I'm not sure how any of these could cause a problem (rhetorical question).
Edit-
If you don't mind, how would using static in particular cause me a problem?
#21942 - sajiimori - Wed Jun 09, 2004 10:59 pm
| Quote: |
a is an integer with global scope
b is an integer with file scope
c is an integer whose data persists and has f() scope
d is an integer that will be shared amongst all instances of X
|
What they all have in common is that they are allocated in RAM before main() even starts.
Again, I don't mean "static" the keyword -- I mean persistent data. The reason I asked is because I've seen people do things like this and wonder what the problem is:
#21961 - tepples - Thu Jun 10, 2004 2:32 am
| sajiimori wrote: |
| I don't mean "static" the keyword -- I mean persistent data. |
"Persistent" can mean one of two different things: data that never changes within one build of the program to the next (called 'const' data around here) and variables whose changes are preserved from one run of the program to the next (called a 'savegame').
| Quote: |
| The reason I asked is because I've seen people do things like this and wonder what the problem is: |
That's lacking only an EWRAM section attribute on the definition.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#21962 - wintermute - Thu Jun 10, 2004 2:44 am
| johnny_north wrote: |
I?m hoping that someone?s conquered a similar problem and can help me cut down what?s looking like a lengthy bug hunt (the code in this file spans nearly 2000 lines and roughly half of it is interdependent). Any ideas? |
almost impossible to say without further information. The first thing I'd do is generate a mapfile and look for memory overruns.
Another possibility is an alignment problem if you're linking binary data using objcopy or some sort of bin2o tool.
There's a win32 port of Insight on http://www.devkit.tk which might help you narrow it down.