devkitPro

Hi,

I created a Wifi debugging patch a while ago, but it was a bit flaky and I was told it would never work properly (something to do with Wifi hardware being controlled from a different processor). Because of this, I recently bought a USB Gekko. I can use wiiload to upload my elf files, and can debug using powerpc_gekko-gdb.exe, however GDB is extremely slow. It can take around 15 seconds to step through each line of code.

So I'd like to know if this is normal? Does anybody know of a way to speed this up. As it stands I would have to reserve debugging as a last resort. I remember my Wifi debugging patch was much faster.

One other problem is that I can't interrupt GDB. If I continue without any breakpoints set, GDB will not accept any further input to set new breakpoints. I have used other versions of GDB that allow you to CTRL-C to interrupt the program, then you can set new breakpoints. Is this supposed to work? I remember the same problem with my Wifi patch, but though maybe it was something wrong with my code. Would it be possible to modify GDB or the stub to support interrupts? If not I could always modify my engine to call _break() whenever a certain button combination is pressed.

Thanks,
cdmac

Tonight I installed Ubuntu Linux and tried GDB (after hours trying to get it to compile). USB Gecko debugging now works lightning fast. I think I will try a few Linux remote debuggers for convenience, but it would still be nice to know why GDB is so slow in Windows.

Would it be possible to provide Linux binaries for GDB and Insight?

Thanks,
Aaron

devkitPPC comes with a gdb binary. Currently I have no plans for a linux insight binary.

The speed thing on windows is a touch odd, it certainly worked fine for me the last time I tried. Which windows version are you using & have you tried changing the default baud rate on the virtual com port?

The GDB stub uses polled communications so I'm not entirely sure about the feasibility of implementing an inferior interrupt. Generally speaking most people use other methods to track down the area of a bug before using a debugger anyway.

I've tried on two PCs, one with XP Home SP3 and the other with XP Pro SP3. I did try changing the baud rate, as the default was set pretty low. Strangely when I changed it and went back into the dialog, it had reset itself. When changing it again, it stayed at the higher baud rate. This happened on both machines, and makes me think that the setting has not changed correctly.