You are not logged in.
Pages: 1
Helpful note: When debugging it is helpful to compile your NDS code with the -O0 optimisation setting. Using the -O2 setting may reorder/remove sections of code meaning stepping may not follow the expected path through the source file and variables may get optimised away so that you cannot examine their value.
I have updated my GDB debugger stub code. The stub is pretty much fully featured now (watchpoint are supported now for example). The only thing that you cannot do is change the CPSR register value (I have not currently implemented this in the ARM emulation code). You can find the Desmume source code plus the stubs here (you want the desmume-gdb-20070423.tar.bz2 file).
The code for the stubs is in the CLI, GTK and Windows ports. The CLI and GTK builds should happily build if you have autotools installed on your system. You will have to add the gdbstub.c source file and wsock32.lib (part of the platform SDK) to the Windows build environment (I have built the code using Visual C++ express edition).
The stubs are enabled, in the CLI and GTK builds, by passing --arm9gdb=<PORT_NUM> (for the ARM9) and/or --arm7gdb=<PORT_NUM> (for the ARM7) options when running Desmume (--help option will give some help). The <PORT_NUM> is the TCP port the stub will listen on for GDB connections. Desmume will happily run as normal if you do not enable the stub(s).
For the Windows port you will have to edit the source code. In main.c set the variable arm9_gdb_port to the port number you want to use (arm7_gdb_port for the ARM7).
Grab or build an ARM targeted version of GDB or Insight (if building from source run something like ./configure --target=arm-none-eabi --prefix=/opt/local). I would recommend version 6.6 as I have seen problems when using earlier versions. You can get pre-built older versions from www.codesourcery.com.
Load the .nds file you want to debug into Desmume.
Then run gdb or insight with the corresponding .elf file (ARM9 or ARM7) and connect to the TCP port you select (the command under gdb is target remote :20000 assuming you selected port 20000). Debug to your hearts content.
From a Desmume point of view I have put an interface between the ARM cpu emulation and the memory system. This means that the memory system and ARM emulation do not need to be aware of GDB stubs and the GDB stubs do not have to be aware of the workings of the ARM emulation and memory system. This makes it easy to enable the stubs at runtime and should mean the code is easy to maintain.
Before I think about commit this to CVS I am interested to hear people's experiences of running this version of Desmume both for debugging and under normal use.
One feature I am thinking of of implementing is sticky input. By which I mean you would press and release a key once to "press" the corresponding NDS key to and then do it again to "release" the NDS key. Something similar with the stylus using the right mouse button to place/release the stylus on the screen and the left mouse button to move it.
Last edited by masscat (2007-05-18 09:40:24)
Offline
I have updated the Desmume plus GDB stub to the same code base as Desmume release 0.7 (no change to the stub functionality).
You can get the source and a pre-built Windows binary from here.
desmume-0.7.0-gdbstub_2007_05_12.tar.bz2 - this is the source code.
desmume-0.7.0-gdbstub-win32-2007_05_12.zip - this file is the Windows binary.
The Windows build now has command line options as described in the first post (i.e. enable the gdb stub with --arm9gdb=<PORT_NUM> and --arm7gdb=<PORT_NUM>).
Both versions have a command line option to use the compact flash emulation described in this thread.
To use this pass the argument --cflash=<path_to_disk_image_file>.
Without the --cflash option the normal compact flash emulation will be used.
The Windows build and source are not an official Desmume release. They are issued to allow people to test and use the debug stub feature before (possibly) being placed in the main CVS. Do not raise bug reports for problems found in this source/build against the official Desmume release use this thread instead.
Please do post a reply if you use the GDB stub (successfully or otherwise).
Offline
I'll try it when I dev stuff for the DS again, but I didn't have the needed time lately. Anyway, kudos, that'll surely be helpful, so I don't need hell a lot of on-screen debug messages to know where the app crashes.
Offline
Thanks for this! I used the Windows build and it worked very well. I had one issue, though. I was trying to track down a crash bug in my program, so I ran it with the debugger. When it reached the crash, Insight lost connection with Desmume and hung. I couldn't find where in the code the crash was occurring until I stepped through line by line.
The crash turned out to be because of a bad function pointer. You can easily reproduce the case with something like this:
void (*foo)(int) = NULL;
foo(2);
Last edited by eddie (2007-05-22 02:03:16)
Offline
eddie:
Thank you for your report.
I cannot reproduce the problem.
I have taken the arm9 template from devkitpro examples and added the foo null function code to the main function.
After the foo(2) call, Desmume executes what is in memory from 0x00000000 to 0x01FFFFFF (ITCM), which is zero (decodes as a NOP ARM or THUMB instruction). The _startup code lives at 0x02000000, so the code simply sits there looping with the stub and Insight happily talking to each other.
What version of Insight/GDB are you using? I had problems with versions earlier than 6.6 stepping through the _startup code (it would not correctly step causing the target to run freely and have seen it seg fault).
NOTE: The above Desmume behaviour is not correct as, assuming that the protections unit set up has not been changed, executing address 0x00000000 will cause an exception on hardware. The PU is not currently emulated (at least the code for some of its emulation is not enabled).
Offline
Well, I'm stuck with what came with devkitpro, which is version 6.5. I downloaded Insight 6.6, but building for a windows host didn't work.
Offline
Well i couldnt get QuakeDS with the --cflash parameter to work on windows.
It fails the FAT.
Gonna upload a screenshot later.
Athlon 64 X2 3800+ / 2Gb DDR2 800Mhz
Geforce 8600GT 256MB / Windows XP PRO SP3
http://desmume.org/compatibility-list/
Offline
Desmume will silently fail if it cannot find the image file. Make sure you supply the full path to the FAT image file.
I just made a FAT image (quake.image on the root of my D: drive) with the Java application (35MiB) and copied in an ID1 directory containing PAK0.PAK (shareware file) and CONFIG.CFG. Running Desmume as follows works for me:
DeSmuME_gdb.exe --cflash=D:\quake.image
Offline
I had some time to look into the issue I was having--I think the problem is Insight. I tested a simple while (true) {...} loop, and I was almost never able to break execution without Insight losing the connection. I then tried it with the GDB console, and was able to break and resume without problems.
Anyways, thanks for your help, masscat. The stub has been extremely useful for me.
Offline
Ah so i have to copy the game contents to the image file...
Thx for the tip gonna try later.
Athlon 64 X2 3800+ / 2Gb DDR2 800Mhz
Geforce 8600GT 256MB / Windows XP PRO SP3
http://desmume.org/compatibility-list/
Offline
masscat, this is brilliant. Literally took me 20 minutes to fetch, build and install desmume and insight and i am stepping through code now.
Offline
...and optimized-away variables are clearly shown in local variables view, and sure enough are affected by choice of level 0 or level 2 optimizations, as masscat stated.
Offline
I tried using this and I'm having intermittent network problems. This is on Windows XP. The tool works randomly about one in every 25 times I run it. :-( Here's what happens when I try to debug ds_2dand3d.nds:
1) C:\util\desmume\DeSmuME_gdb.exe --arm9gdb=24689 ds_2dand3d.nds
2) C:\util\devkitPro\insight\bin\arm-eabi-gd.exe ds_2dand3d.elf
GNU gdb 6.5.0
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=arm-eabi"...
(gdb) target remote :24689
:24689: No connection could be made because the target machine actively refused
it.
(gdb) quit
If I run netstat after running desmume_gdb.exe I see:
TCP 127.0.0.1:4788 127.0.0.1:24689 ESTABLISHED
TCP 127.0.0.1:24689 127.0.0.1:4788 ESTABLISHED
Which looks like desmume opened port 24689 then connected to itself. (???) Although it does this same thing even when it does work.
Offline
I think either gdb or desmume isn't closing TCP connections properly. It's working right now, but it didn't work 5 minutes ago... And netstat looks normal now, showing LISTENING instead of ESTABLISHED. Except for my weird TCP problem -- it works great! I definitely think it should be added to the trunk of desmume. I haven't used it too much, but so far there don't seem to be any compatibility problems.
Offline
Hi guys,
I am having a problem using the above mechanism with the latest version of Desmume on Windows Vista. It works fine with a previous version (0.7.2) - as soon as I start Desmume 0.7.2, Windows Firewall prompts me if I want to unblock. When I load the rom, it waits for a connection from GDB, and I can subsequently connect fine with GDB.
However, with the latest version (0.9.1), I get no prompt from Windows Firewall upon starting the emulator, meaning that the emulator is not listening for any connections. As soon as I load a rom, it begins normally (as if I did not enable the debugger stub at all). I then cannot connect from GDB.
Any opinions on why this might be happening?
Cheers for your help.
Offline
The public win32 releases of desmume are not being built with the GDB stub. You may build it yourself by adding GDB_STUB define to the project. This hasnt been tested in a while.
I will analyze GDB_STUB to see whether it hurts the emulator performance. If it doesnt, then I will consider including it in the public builds.
In general, I am considering making an entirely separate devvers build, which might include a number of features which hurt performance. If this release ever appears, rest assured that it will have GDB enabled.
If you are considering making heavy use of the GDB feature in the near future, then I urge you to come on IRC and hang out for a while and we can work on making sure that it is solid.
Offline
I was hacking around and managed to integrate the existing GDB stub code with the Mac OS X (Cocoa) port. I gave it a try and it seems to work, though I haven't much experience using GDB. In any case, I've built a binary from the current SVN, with the GDB stub enabled, and posted it here. Hopefully it's useful to others working on DS homebrew on the Mac.
Offline
Can you come on irc and help us get it checked in and tested and make mac builds? We are wanting to release soon and it would be nice to have official mac releases.
Offline
Pages: 1