New Debugger branch - Functional

[DarkJezter]

Just thought I'd open some dialog on the graphical debugger. As of right now I have it working, and anyone who would like to play with it can try the debugger branch of the SVN tree. It's still using the original GTK gui, and I haven't tested it yet with the new KDE4 interface.



I'm eager to build onto what's here, but before I do that I'd like to know first off that what's here now is portable enough to be used elsewhere. If it isn't, then I'd like to make that a first priority.


Anyways, in the mean time here are a few hair-brained ideas that I'd like to see come out of this tool:
OProfile support - performance analysis of native r4300 and recompiled code
Integration into cheat system - for uber geeks who want to make their own cheat codes
Register & Ram edit - because every debugger should have these

Other ideas - extract images & textures from roms, view memory


Anyone else have any thoughts?

[Richard42]

OProfile integration would be nice (the current method works but is somewhat tedious) but not very useful for most people.

Cheat system integration would be good. XMAME/XMESS has a simple system for cheat discovery which is easy to use and works well.

More debugging functions: register and RAM edit would go here. It would also be nice to be able to set breakpoints and watchpoints.

[DarkJezter]

Richard, you got any issues with me merging the fixes to the debugger back to the trunk before I start ripping it apart?

[Richard42]

Richard, you got any issues with me merging the fixes to the debugger back to the trunk before I start ripping it apart?

Nope, go ahead. I was going to do it but am kind of swamped at the moment. Be sure to note the start and end rev of the branch that you're merging in the commit message on the trunk. That way it will be easier to find the right information to merge the remaining part of the branch.

[DarkJezter]

Ok, so the only thing I have not been able to test is the debugger built alongside the KDE4 gui...

Not sure if this is because I'm still running kde 3.5 or not, but I haven't been able to get KDE4 to compile at all. I'm guessing this is the case, or that there is a related dependency that's missing.

From what I gather it should compile fine, and should work... once the KDE gui has a menu added to allow enabling/disabling the debugger.


I hope this doesn't cause any head scratching, but the fixes thus far are only to 3 files, and instead of merging the branch, I've just committed those changes to the trunk. This way I'll just continue the rest of the work from the current debugger branch.

[Slougi]

I'll look into adding support in the KDE4 interface as soon as I have some spare time. I'll probably implement the cheat stuff as well and flesh out the config stuff. Just a fyi, I'm quite busy at the moment.

[Richard42]

Yeah everybody's pretty busy at the moment; development has slowed a little. I hope to get the makefiles written for your KDE4 port this weekend, and the regression tests up and running. I have the first 1/3rd of the regtest script done and tested; it's pretty cool.

[DarkJezter]

I've been playing around with the debugger. I currently have the breakpoints working in the interpreted cores, and have started work on displaying generated dynarec code. Once I have this working, I'm planning on getting breakpoints working with the dynamic recompiler, as well as single step instruction stepping, (either via the dynarec or if enough state is persistent and present, possibly by using the interpreted cores)

Splitting the code is almost done, the only thing that's really left to split up is reading registers. Modifying registers will come next. I suppose after that, a memory viewer/editor would be nice

[MIO0]

I think it would be helpful to use the symbolic general purpose register names instead of the numeric ones, and shrink down the window sizes. Perhaps a smaller font and less padding?

There are a couple of appearance bugs: the last digit and a half are cut off in the register text fields and the register labels do not line up.

[HyperHacker]

OK, yes, suggestions, some quite obvious :

• RAM editing
• Instruction editing ala No$GMB would be nice too (double-click an instruction and type in new code to replace it). Although No$GMB's only allows one opcode at a time, a better way would be a multi-line textbox to replace multiple instructions starting from the selected one.
• Split the giant register window into multiple windows. One for GPR, and special, one for the others using the tab system it's got now. And of course register value editing.
• Display the register contents in a fixed-width font.
• Breakpoints on memory access (individual bytes, not just words, and including DMA access if possible - two things that drove me nuts in Nemu) [edit: done ]
• Be able to close the windows and open them again from the menu
• Break when a specified register ==/>=/<=/!= a specified value or is changed by a given amount

I've been using Nemu on Windows for a while for ROM hacking and man it's buggy. The idea of a decent debugger makes me very excited, especially an open-source Linux native one.

Also, bug reports:

• Shouldn't "Desassembler" be "Disassembler"?
• If I double-click an instruction, it adds a breakpoint for that address, but if I do it again, it doesn't get removed from the list, only grayed out (disabled?), and the first time I did, it also added one for 0x0.

Any way I can get involved in trying to add some of these features myself? /me looks into the breakpoint code to see if he can hack together memory-access breakpoints, and fixes the spelling error in desasm.c:71

[edit] Already fixed one bug around line 220 of gui_gtk/debugger/breakpoints.c:

gtk_clist_set_text( GTK_CLIST(clBreakpoints), new_row, 0, (gpointer) address);

'address' should be 'line[0]'; it's a pointer to a string, not a hex number. No more segfault when clicking "Add" while the game is running.