Homebrew Debugging

  • Thread starter Thread starter gudenau
  • Start date Start date
  • Views Views 4,518
  • Replies Replies 11
I think that no$gba is still the greatest debugger for nds, though I never tried other emulators ones. I don't think you can debug directly on nds, if it is your homebrew then you only have to output messages, easiest way of debugging
 
You might want to read this : http://www.console-dev.de/2009/09/20/guru-meditation-error-data-abort-exception/ ; it explains how to use the "guru meditation error" you might sometimes see in homebrew games (among other things) to debug your games. Basically, every time your program crashes, it will give you information which you can use to know which line of your code is faulty. Of course, it's only one tool and it won't give useful information every time, but it's better than nothing, and it'll work on the DS (you don't need an emulator to get it to work).
 
Whats the game? Most run fine on nogba

The ds emulators don't like to run on my computer.

You might want to read this : http://www.console-d...bort-exception/ ; it explains how to use the "guru meditation error" you might sometimes see in homebrew games (among other things) to debug your games. Basically, every time your program crashes, it will give you information which you can use to know which line of your code is faulty. Of course, it's only one tool and it won't give useful information every time, but it's better than nothing, and it'll work on the DS (you don't need an emulator to get it to work).

Thanks.
 
You could also use the console to print info to the screen. It's very limited, but it'll get you some more info on specific variables.

My game framework contains, among other debugging functions, simple logging options that can be accessed at any time while playing, and automatically gets saved to the sd card when it crashes with said guru exceptions; See my level editor app for an example (link in my sig, press select+L+R). It's easy enough to make, and I find it very useful, though the logs do take up some memory (if memory is an issue for you).
 
Yea. Pretty much your debugging choices are:
- No$GBA Debugger: Awesome debugger, but bad emulator. Supports breakpoints and many other stuff, console printing, but doesn't support DLDI :(
- Desmume: You can print out with it if you use the dev+ builds, accurate emulation, DLDI supporting
- Real DS: you can just use the guru error screen, and libnds console. The guru error doesn't catch all kinds of errors though.

The one I always use is demume. It's accurate as hell :)

You might want to read this : http://www.console-d...bort-exception/ ; it explains how to use the "guru meditation error" you might sometimes see in homebrew games (among other things) to debug your games. Basically, every time your program crashes, it will give you information which you can use to know which line of your code is faulty. Of course, it's only one tool and it won't give useful information every time, but it's better than nothing, and it'll work on the DS (you don't need an emulator to get it to work).

I always open the .ELF file in IDA Pro and look up the faulty addresses. You can get many, many more info this way, you can look at the registers and see what variable they are :) That, eif you know how to read ARM assembler code :)
 
- No$GBA Debugger: Awesome debugger, but bad emulator. Supports breakpoints and many other stuff, console printing, but doesn't support DLDI :(
With the FCSR thing, you can build your filesystem into a single *.nds executable that no$gba can load. It's read-only, but it works for testing sometimes. I usually used the DLDIrc addon to quickly build my FCSR images for testing. If you're interested I can give more detailed instructions and a more stable image builder tool.
 
Hehe when i get guru's I use the arm-eabi-objdump tool you provide it with an .elf and it gives a conplete dissembly. Work's like a free version of IDA's .elf reader. (but you cant hack .arm9 in games with it xD).
In terms of debugging you could also make a ram dump to a file.(and a vram  dump if you are really needy) then just print the offsets of all your variables to a file. Allowing you to check everything. Also you could make it read ram dumps so you can modify variables and see what happens. Although my preferred debugger is desmume, this is because it has not only Dldi, but also can read ram, view vram, and heaps more. The only thing it can't do is dissemblies.
But yeah, try ram dumping to see whats happening - that is without an emulator.
 
Yeah, I've used desmume's GDB too, but it's way too unstable for me. It tends to hang / screw up/ crash :(

It works a bit more reliably if using Insight as a GDB client instead of IDA but it's still far from ideal.
 

Site & Scene News

Popular threads in this forum