#143632 - cheese_block - Wed Oct 24, 2007 9:46 pm
Been reading through the various posts concerning DS debugging. I'm looking for source level debugging.
I've messed around with Insight/GDB, it seems to work for the simple example programs, but doesn't seem to work well for the more complex. I've considered no$cash, but the $1750 is currently out of my price range. Does the $15 version give you much more?
I wondered what everyone's technique is for debugging their code. Text to screen is fine when you're not using both screen to show much. Do any of the emulators have an output window you can write to?
Are there any other alternatives?
I'm going to continue trying to get insight to work a bit better, any tips would be appreciated.
#143634 - sajiimori - Wed Oct 24, 2007 9:57 pm
If it were me, I'd get the game code to compile on Windows and use the Visual Studio debugger. There's really no contest in terms of quality.
I'd use the VisualBoyAdvance source to emulate the 2D hardware, and a higher-level layer to wrap 3D calls.
#143664 - DragonMinded - Thu Oct 25, 2007 1:54 am
I know it's not the best way, but I do all my debugging by writes to the filesystem or to the screen. I have a debug flag I can compile in which turns the top screen into a console, so I can track down crash bugs. I also have a debug to disc function that will write to the fat system instead of the screen when it's inconvenient to display anything. As far as debugging in an emulator, I've never tried.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#143690 - DekuTree64 - Thu Oct 25, 2007 10:13 am
I have asserts that can print messages/variable values when they fire, and a button combo to swap the top screen to printf output. I need to give it a real output buffer though, so I can have more than one screen's worth of stuff to look through if it dies (currently just prints to a screen block that I'm not using for anything else).
And most importantly, I have a wireless card with ralink chipset, so I can multiboot rather than card swapping. Next I need to set up wifilib so I can download and run without even turning the DS off and on :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#143703 - simonjhall - Thu Oct 25, 2007 1:52 pm
I'm gonna update and re-release the target debugger I wrote last year, adding some new features, fixing some bugs etc. Hopefully will do this after this weekend or something...
Should be esp handy now that a gdb comes with r21.
_________________
Big thanks to everyone who donated for Quake2
#143745 - HyperHacker - Thu Oct 25, 2007 8:19 pm
Yeah, I just add printfs and/or button press checks as needed and remove them when I'm done. It's not great but it works. I'd implement a simple wifi console sort of thing (send text to PC to display on the screen) but I imagine it'd be more work than the majority of the debugging. :-p
_________________
I'm a PSP hacker now, but I still <3 DS.
#143770 - wintermute - Thu Oct 25, 2007 10:13 pm
| simonjhall wrote: |
I'm gonna update and re-release the target debugger I wrote last year, adding some new features, fixing some bugs etc. Hopefully will do this after this weekend or something...
Should be esp handy now that a gdb comes with r21. |
Cool, sort out the evil lawyers then?
I'd quite like to get some version of a gdb stub into the devkitARM distribution fairly soon - that was one of the reasons for adding gdb in there.
Recently I've been playing with masscat's stub and DSerial but right now I'm having trouble getting it to connect at anything other than 9600baud. Would you and Masscat be interested in collaborating on the stub code? How would you feel about a stub library being included as part of the toolchain setup?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#143811 - simonjhall - Fri Oct 26, 2007 9:22 am
| wintermute wrote: |
| Cool, sort out the evil lawyers then? |
Well... ;-)
I've just spent a bit of time thinking about this (during my dull journey to work). I'd love to get a bit of debuggin' love into the toolchain, as being able to debug is pretty crucial to writing code. However, given how infrequently people have asked for debugging on here, and there wasn't a very big response to what I released, I'm wondering if people want debugging after all. If people were writing a piece of software and made it compile under visual studio (or whatever) then being able to debug with that is far more productive than doing it on the DS over wifi! On the flip side, being able to debug on the real machine has been completely invaluable for me when writing Quake (esp as you can view all the hardware I/O registers etc) so it can be more useful than running on a PC.
I dunno...what are other people's thought's on this?
With regards to collaborating, yeah, I'm up for that. However that does sound like a complete re-write to me when all I was thinking of doing was making a few small fixes and then re-releasing! Hmm... :-)
_________________
Big thanks to everyone who donated for Quake2
#143832 - masscat - Fri Oct 26, 2007 3:08 pm
My GDB stub code is public domain (as is the GDB stub code in Desmume - the two are very similar with the Desmume stuff being more developed) so if anybody wants to play around with it then please do. I would like to get it into a better condition but have not given it the time and I am not sure when I will be able to.
The biggest problem I was finding was that debugging the debugger is not the easiest thing or that much fun. Trying to debug the debugger was the original reason for the GDB stub in Desmume but Desmume is not capable of emulating the hardware features to run the on hardware GDB stub (too many GDB stubs) so I never used it to develop the on hardware stub further.
There is definitely value of an on hardware debugger. But without a stub in a reasonable state (it is easy to break my on hardware stub with it wondering off never to return) that is easy to incorporate into a project people will not use it.
If a debugger stub does get into the tool-chain then there is an opportunity to solve the second part of the problem.
As for off hardware development I would recommend using Desmume with GDB (or compatible). The Desmume GDB stub allows near full GDB features support (breakpoints, watchpoints and the like). The stub is stable and you can believe what it tells you (I used it to develop Flickbook).
#143855 - cheese_block - Fri Oct 26, 2007 8:59 pm
Thanks for the replies guys.
I for one would love some debugging action. It surprises me that people stick with text output (though I'm really impressed with quality that this has produced). I think adding good source level debugging to the toolchain would certainly help the homebrew community.
Debugging with something like Visual Studio would be the ultimate for me, it's what I'm used to. But debugging on the hardware would also be fantastic.
#143863 - simonjhall - Fri Oct 26, 2007 10:02 pm
| masscat wrote: |
| The biggest problem I was finding was that debugging the debugger is not the easiest thing or that much fun |
Hear hear! I dunno about you, but writing the debugger was one of the most fiddly things I've ever written! The whole thing with the ARM $pc being ahead of where it really is (but how far it is ahead depends on the type of abort) was seriously annoying. Bravo ARM, bravo.
However stuff like this is why I made my one a two-part debugger - the DS-side thing was very simple, and all the hard work was done on the PC (which allowed me do debug it). If I were to re-write it I'd still keep a PC-side controller/cache program. However this did mean that I managed to get pretty much ever bug out of it, and it's now steady-as. All I want now is ARM7 debugging...
We could always pass the torch to programmer #3, assuming they were masochistic enough!
EDIT, cheese, yeah the speed of visual studio is a bit of a way off (the wifi makes it slow) but here's wintermute's picture from a year ago:
http://devkitpro.sourceforge.net/debugging.png
_________________
Big thanks to everyone who donated for Quake2
#143875 - gmiller - Sat Oct 27, 2007 12:45 am
if you have the GDB stub then you should be able to connect the insight debugger included with the devkitARm stuff and go to town. I use that setup to debug code running on my GP2X and the debugger running on my PC. I also do the same thing with the Game Boy Advanced emulator and GBA code running on the same PC.
#143881 - kusma - Sat Oct 27, 2007 12:55 am
| simonjhall wrote: |
| Bravo ARM, bravo. |
*bows*
#143891 - M3d10n - Sat Oct 27, 2007 3:06 am
I try to develop and test all logic stuff on a PC first. With some #ifdef usage I can use the same .h and .cpp files in both the PC and the DS executable.
I haven't had the courage to write graphical code to simulate the DS output, so graphics-related code must be tested on emus or hardware. I plan to do it someday, after I manage to abstract all graphical functions behind my own graphics layer.