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.
]]>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.
]]>Anyways, thanks for your help, masscat. The stub has been extremely useful for me.
]]>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