#12255 - xjorma - Wed Nov 05, 2003 8:08 pm
Hi,
This afternoon I had hard time with vba and insight.
The VBA implementation of gbd seems very buggy. Before retrying to use it I want to know if there are some happy user of it.
Is possible to debug whole game with it or only small program ?
Try tryed to use it with .elf compiled with the "devkit advance" and also the "official tool chain". The both works but sometimes ( lot of times ) when I step I lose the control.
What is the limitations of this tools ?
How can I make it work perfectly ?
David.
#12285 - johnny_north - Thu Nov 06, 2003 3:47 pm
First of all, what operating system are you using? My experiences relate to Win98. Also, Tepples has included a brief bit of info in this forum's faq - be sure to read it.
My experience is this - if you've used other enterprise level visual debuggers then GDB may be a bit of a dissappointment and frustration, but if your projects are homebrew and large (read: lots of effort on a shoestring budget) it's probably the best tool you'll have.
I have learned to work with the problems because source level debugging is indespensible as far as I'm concerned.
My two biggest problems are these (Win98):
1)Stepping through code after a break point is painfully slow. I've read that this is not the case with XP and the Linux pipe system is also better.
2)Insight/GDB frequently chrashes and refuses to restart when I choose to exit the program. This tends to happen when I find a bug, quit GDB, recompile and restart GDB. Occasionally, GDB will restart after waiting for a prolonged period, but frequently I will need to shutdown and restart the entire computer.
I definitely recommend writing a script or .bat file to start VBA sdl and GDB with the appropriate options with a single double click. This will save you time.
In short, I don't know how to make it work perfectly. I debug a relatively large project with roughly 15 source files - I don't think project size is an issue at all.
For all of its headaches though, I sure wish I could use it to debug multiplayer code - that's a function of VBA's inabilities in this area though.
#12347 - ampz - Sat Nov 08, 2003 3:31 pm
Sounds like GDB is a poorly written piece of software.
Is there a GDB stub for debugging on GBA hardware? (using a link cable or something..)
#12357 - torne - Sat Nov 08, 2003 8:29 pm
The issues with GDB are related to the stub in VBA, not the debugger itself. GDB is reliable and powerful in general; the majority of non-GBA ARM developers use GDB to debug their code as it's more flexible than ARM's debugger, and Angel implements a GDB stub just fine.
The GBA is vastly impeded by the fact that it loads raw binaries. It's hard to debug those on any platform; sectioned code is easier for a stub to understand.
#12358 - ampz - Sat Nov 08, 2003 9:13 pm
Code in RAM should be easy enough to debug.
The IAR IDE has a very good visual debugger. IAR is overall actually a good visual IDE.
What I don't like with the GNU tools is the constant typing at the commandprompt.
Texas Instruments even have a visual linker in their visual IDE for DSP's. It's a great tool. You can drag-and-drop pieces of code, files, and variables between the different memory areas.
#12370 - torne - Sun Nov 09, 2003 2:09 pm
Most people, myself included, prefer to type at a command prompt than use a visual debugger (I use DDD for regular debugging). None of the problems related to GBA debugging would be fixed by using a visual debugger, of course. =)