How to use debugger?

[obcd]

I was wondering if there is a good tutorial available somewhere that describes how you can use the gdb and insight debugging tools?
As those are also used for Android development, most google hits refer to using it for that.
I have a little experience in embedded programming and I know that usually debugging on such architecture hardly works.
I hope I am not getting off topic now.
The desmume emulator seems to have a gdbstub that makes it possible to control it from gdb and insight.
I had to return to version 0.7.2 before I finally could execute some arm7 code and make it stop at my breakpoint.
I compiled the 0.9.1 with the gdb stubs enabled, and it seems to work as well. The 0.9.4 and all later versions don't work anymore. If I press "C" (continue) in the gdb window, it never stops at it's breakpoint.
I know you will flame me and say that it's "off topic" as it's likely a desmume bug.
I agree with that, but haven't found an alternative so far.
I post the details so that others following the same path know what they can expect.
I assume I am not the only one running into those issues struggling with my first homebrew, which is why I am posting here.

Basically, these are the steps I am following.

Start desmume with the command line options --arm7gdb=1000 and --arm9gdb=1001
Load the nds file in desmume the normal way

Start arm-eabi-gdb and run the following commands:

target remote 127.0.0.1:1000
file c:/loader/arm7/loader.arm7.elf (The arm 7 part of the nds file)
b main.c:50 (the line number where the arm 7 main function starts.
c (continue)
After the break appearing in gdb, I can step trough the code using the s command.
I am testing with GDB instead of insight as it is a bit more basic.
I assume I can generate a similar more user friendly behavour with the arm-eabi-insight.

Thanks in advance for those willing to answer.

[elhobbs]

The gdb stub in desmume is not 100%. I always had to set breakpoints before continuing after the main breakpoint. Last I knew you had to compile it yourself to enable the gdb stubs which appears to support what you are seeing. And occasionally it is broken when you are compling the latest svn. Also make sure you are compiling your ds code with optimizations turned off or things will definitely be a little wonky.

I have mostly given up on the gdb stubs it is just too slow. I have been cross compiling to windows for debugging core logic. The VRAM viewers in desmume are fantastic though for troubleshooting your VRAM layout.

[obcd]

Thanks for the reply, altough, not exactly what I was hoping to hear.
If I understand well, there is no better alternative for the moment.

I was trying to reproduce the nds_loader code. Everything seems to run till it reaches the swi_SoftReset(). (The last instruction)

It looks like something that changed in the toolchain breaks the code.
The precompiled nds_loader file that comes with the source works as expected.
Other examples I found to launch a program seem to be based upon the same loader source.

The idea is to have a ftp server that can launch a program after it was transferred with ftp.
The program should have a sort of watchdog that reset the ds if it isn't triggered anymore like in the case of a hang. That way, I could cycle between the ftp server and the program without the need to constantly manipulate the power switch.
It looks like a fragile piece of hardware, specially since my replacement one isn't having the 2 support points on it's front site.

I know wifi ftp isn't fast, but for homebrew it should be fine.