#24947 - Gene Ostrowski - Fri Aug 13, 2004 8:03 pm
Not sure where to post this, but I stumbled across something that some of you may not yet know, and it was very helpful.
I had something happening in my program where it appeared to be locking up, and I could not track down the code where it was occurring.
Sometimes stepping through the GDB debugger is a slow and painful process, but I figured out a fast way to find out where it was hanging:
By using VBA in conjunction with the memory map, I was able to determine the exact routine that was causing the problem almost instantly.
VBA comes with a built-in disassembler that can be accessed through the Tools --> Disassemble menu. Load up your ROM and open up the Disassemble window while the game is running. Click on the "Automatic Update" box and you'll see your code executing. More importantly, it will show you the address that is currently executing (the left-most column on the screen).
You can then use NM to map out your symbols for you, so you can determine the routine that's associated within that address space. From the command-line, do something like:
nm -n MyGame.elf > MyGame.txt
to dump the memory map to a file (MyGame.txt) then open it up in a text editor. Scroll down for the routine that includes the address in question, and you can pinpoint the location of the problem. At least you'll know which routine it is.
Similarly, you can use the Tools -> Memory Viewer menu option to display a memory map. If you are needing to watch a variable because you think it contains an incorrect value, you can scan for the name in the text file, get its address, and use the memory viewer to watch the variable in real-time.
I used this method to find the routine that was hanging, and the variable that was being overwriten to a bad value.
Hope this helps someone!
_________________
------------------
Gene Ostrowski
I had something happening in my program where it appeared to be locking up, and I could not track down the code where it was occurring.
Sometimes stepping through the GDB debugger is a slow and painful process, but I figured out a fast way to find out where it was hanging:
By using VBA in conjunction with the memory map, I was able to determine the exact routine that was causing the problem almost instantly.
VBA comes with a built-in disassembler that can be accessed through the Tools --> Disassemble menu. Load up your ROM and open up the Disassemble window while the game is running. Click on the "Automatic Update" box and you'll see your code executing. More importantly, it will show you the address that is currently executing (the left-most column on the screen).
You can then use NM to map out your symbols for you, so you can determine the routine that's associated within that address space. From the command-line, do something like:
nm -n MyGame.elf > MyGame.txt
to dump the memory map to a file (MyGame.txt) then open it up in a text editor. Scroll down for the routine that includes the address in question, and you can pinpoint the location of the problem. At least you'll know which routine it is.
Similarly, you can use the Tools -> Memory Viewer menu option to display a memory map. If you are needing to watch a variable because you think it contains an incorrect value, you can scan for the name in the text file, get its address, and use the memory viewer to watch the variable in real-time.
I used this method to find the routine that was hanging, and the variable that was being overwriten to a bad value.
Hope this helps someone!
_________________
------------------
Gene Ostrowski