Fun with Compiling, or not so much..

[TrashyMG]

I'm using Sebt3's cross compiler and running into this:


cc1plus: error: unrecognized command line option "-mno-fused-madd"


I don't believe this is an ARM supported option for GCC, just seems to be picking it up for some reason.. I can remove the option in the configure file, rerun the pndconfigure and it will compile fine.. But my program seems to hang in a segfault on the Pandora.. I'm not sure if it's related.. but kind of stumped as everything seems to be building fine.. is there a ARM related option I should be substituting instead of just removing the option?


I've finally got some spare time to start building projects for ARM / Pandora in general.. so fairly green at it.

 

[Pickle]

run your app through gdb and find where your segfaulted could be unrelated to the flag

 

[TrashyMG]

Hmm gdb is not a friendly debugging solution for those not familiar with using it and I'm not sure if I got any good information out of it... I'm spoiled with eclipse and generally dealing with my code on the same platform.


I've tried both Sebt3's cross compiler and the C/C++ Dev PND... both solutions seem to result in a segfault and no apparent issues on compiling.


however gdb is complaining with a warning when I start the debuging:

warning: Unable to find libthread_db matching inferior's thread library, thread debuggin will not be available.

 

[Pickle]

dont worry about the warning, gdb is very simple for the test you need to run. Dont run in fullscreen of course.


from the command line run: gdb myapp


within gdb type run


the app will start and run the app like normal and hopefully you trigger the segfault.


next you can type the command backtrace, this will show the call path to where you have segfaulted.


If all goes like described you now should now the exact line that has the problem.

 

[TrashyMG]

Thanks Pickle for the help..


hmm.. this program I'm dealing with seems to go to fullscreen even when I set it to window.. so I need to force out of it with the Pandora button..


Program received signal SIGSEGV, Segmentation fault.


0xe1a0c00c in ?? ()


(gdb) backtrace


#0 0xe1a0c00c in ?? ()


warning: Unable to fetch general register.


warning: Unable to fetch general register.


#1 0x00000000 in ?? ()

 

[Pickle]

what are you using to get the window?


have you compiled with symbols -g (also good not have opto flags like -fomit-frame-pointer)


gdb will say if it detects the symbols and has read them.

 

[Dimacus]

Did you compile it with the -g or -ggdb3 flag? (i'd also remove any -O flags, like -O2 -Os and -s)


edit: ninjad h34r:


Also, If Windows is your native enviroment, it might be worth trying to just compile and run it in a linux vm, since linux seems to be more sensitive to memory leaks.

 

[TrashyMG]

Actually I found a bunch those flags in the configure file... it was a mess to remove them and may of missed some.. re-compiling now...


First dealings with ARM compiling...

Also, If Windows is your native enviroment, it might be worth trying to just compile and run it in a linux vm, since linux seems to be more sensitive to memory leaks.

I haven't primarily booted windows for close to 8 years... working with Sebt3's cross compiler on my linux box..


Edit: Getting closer.. getting the window to appear when debugging. not just a blank screen.

Program received signal SIGSEGV, Segmentation fault

0xe3500000 in ?? ()

 

[sebt3]

You definatly need to add that "-g" to the gcc command to build that program so gdb wouldnt say "??" but the actual function and the line number the segfault happen. Thuss helping to debug


EDIT: as long as you dont use strip later on.

 

[TrashyMG]

More Progress I got somewhere to start looking now:


Program received signal SIGSEGV, Segmentation fault.


0xe3500000 in ?? ()


(gdb) backtrace


#0 0xe3500000 in ?? ()


#1 0x0010bd48 in Wsafile::readfile(SDL_RWops*, int*) ()


#2 0x0010c174 in Wsafile::readdata(int, void*) ()


#3 0x0010c5d0 in Wsafile::Wsafile(SDL_RWops*) ()


#4 0x000dc26c in GFXManager::LoadWsafile(std::string) ()


#5 0x000dd4d8 in GFXManager::GFXManager() ()


#6 0x000555b0 in main ()

 

[sebt3]

#0 0xe3500000 in ?? ()


#1 0x0010bd48 in Wsafile::readfile(SDL_RWops*, int*) ()

I wonder what Wsafile::readfile do because 0xe3500000 is realy far in memory to call a function (probably an unset function pointer, but that's a wild guess before seing the code)


EDIT : I just calculated, 0xe3500000 is at 3.6Gb far the start of that program virtual memory. Sound a bit close to the 32bits CPU memory limit to me.


There is definatly something wrong with a function call somewhere in that function

 

[TrashyMG]

Well what I'm attempting to port over is Dune Legacy a clone of Dune II which is the game that started RTS games as we know it.. you need the original add pak files from the DOS game to play it.. It seems to play fine in x86 linux.. so I know my file sources are good. Was trying to figure it out my own, but I admit I've been neglecting my C/C++ skills for a while.


I think one of the offending functions... or at least the one the dbg is pointing too..

/// Helper method for reading the complete wsa-file into memory.

/**

This method reads the complete file into memory. A pointer to this memory is returned and

should be freed with free when no longer needed.

*/

unsigned char* Wsafile::readfile(SDL_RWops* RWop, int* filesize) {

unsigned char* Filedata;

int WsaFilesize;

if(filesize == NULL) {

  fprintf(stderr, "Wsafile: filesize == NULL!\n");

  exit(EXIT_FAILURE);

}

if(RWop == NULL) {

  fprintf(stderr, "Wsafile: RWop == NULL!\n");

  exit(EXIT_FAILURE);

}

WsaFilesize = SDL_RWseek(RWop,0,SEEK_END);

if(WsaFilesize <= 0) {

  fprintf(stderr,"Wsafile: Cannot determine size of this *.wsa-File!\n");

  exit(EXIT_FAILURE);

}

if(WsaFilesize < 10) {

  fprintf(stderr, "Wsafile: No valid WSA-File: File too small!\n");

  exit(EXIT_FAILURE);

}

if(SDL_RWseek(RWop,0,SEEK_SET) != 0) {

  fprintf(stderr,"Wsafile: Seeking in this *.wsa-File failed!\n");

  exit(EXIT_FAILURE);

}

if( (Filedata = (unsigned char*) malloc(WsaFilesize)) == NULL) {

  fprintf(stderr,"Wsafile: Allocating memory failed!\n");

  exit(EXIT_FAILURE);

}

if(SDL_RWread(RWop, Filedata, WsaFilesize, 1) != 1) {

  fprintf(stderr,"Wsafile: Reading this *.wsa-File failed!\n");

  exit(EXIT_FAILURE);

}

*filesize = WsaFilesize;

return Filedata;

}

 

[sebt3]

ouch SDL_RW functions... That indeed explain the call to a function pointer.


SDL_RW* functions is a way to access and modify the internal of SDL feature. I'm using that in the lastest Zelda port to allow SDL to read the music file directly from the zip data...


SDL_RWops* RWop should point to a struct containing a few function pointer. There should be a function somewhere that is not initialisating that struct correctly.


To find it, that function contain a call to SDL_AllocRW();


Make sure it is indeed called to allocate that RWop struct and that it's "seek" member is correctly set (that's what SDL_RWseek macro is calling behind the scene, and probably the origin of your segfault)