Menu
What's new
By:
Filters

New Debugger branch - Functional

D

DarkJezter

New member
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?
 
R

Richard42

Emulator Developer
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.
 
OP
D

DarkJezter

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

Richard42

Emulator Developer
DarkJezter said:
Richard, you got any issues with me merging the fixes to the debugger back to the trunk before I start ripping it apart?
Click to expand...

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.
 
OP
D

DarkJezter

New member
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.
 
S

Slougi

New member
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.
 
R

Richard42

Emulator Developer
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.
 
OP
D

DarkJezter

New member
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 :D
 
M

MIO0

New member
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

HyperHacker

Raving Lunatic
OK, yes, suggestions, some quite obvious :p:

  • 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 :D]
  • 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. :p 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:
Code: 
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. :p No more segfault when clicking "Add" while the game is running.
 
Last edited:
E

ebenblues

Mupen64Plus Dev.
HyperHacker,

Thanks so much for your help with the debugger. Not sure if you know about this, but svn makes it really easy to create a patch file of your changes. Just cd into the base dir (trunk or r0286-debugger) and type "svn diff > patch". Then open a new issue on our issue tracker site and upload the patch file as an attachment:

http://code.google.com/p/mupen64plus/issues/list

Then you can reference the issue in emutalk and not have to manually type all the changes that need to be made into your post.
 
HyperHacker

HyperHacker

Raving Lunatic
OK, so should I just fix whatever bugs I can find and submit one big patch? Does it matter if that patch also adds one or two new features? (I.E. I've enhanced the breakpoint system to allow setting a breakpoint on a range of addresses, not quite done yet though.)

Most of the bugs I find seem to just be signals not being correctly connected to widgets, causing segfaults when you click buttons. Pretty simple to fix.
 
O

okaygo

Mupen64Plus Dev.
I would submit patches as you see them, that way it might be easier for Jezter to sort through a lot of this stuff. Also thanks for helping out, if you have interest in the development and would like to contribute please feel free to join the development team.
 
HyperHacker

HyperHacker

Raving Lunatic
OK, but say I find one bug, fix it, make a patch, find another one, fix that, won't the second patch have both fixes in it? How do I avoid that?
 
N

nmn

Mupen64Plus Dev.
hmm... Well, All i can think of is to manually exclude. But the others are much better at these sort of things so I'll bet they'll have a more robust solution.
 
OP
D

DarkJezter

New member
HyperHacker, I'm currently working on the debugger branch, and was doing so almost exclusively. I had done most of the necessary work to get the debugger in the trunk debugged so that it would at least compile/function (however it looks like half of that work was undone when the debugger branch was forked)

I'm going to resubmit my patches to the trunk to at least get the trunk to compile and run properly with the debugger enabled.

Beyond that, in the debugger branch I'm currently doing a major rewrite of the disassembler GTK gui. As it is right now, the code for the functional parts of the debugger is mixed in with the GUI, and my first task I'm working on is seperating the two. This is almost done, however the register access needs more work, and I have yet to work on a UI for the memory access.

Once I get my current changes commited to the debugger branch, we'll see if we can't get you svn access. I'd love any help you can offer, however what I need most is someone who can take charge of the look of the debugger, while I clean up the internals.
 
HyperHacker

HyperHacker

Raving Lunatic
Well I imagine I'd be much better at adding and fixing things than GUI work as I've never dealt with GUIs outside of the Windows API before, but GTK looks pretty simple to work with so I can probably make some enhancements here and there. I'm mainly interested in enhancing it though, so that I never have to deal with Nemu in Wine again. ;)

Maybe I'll just fix what I can, submit a few patches, and then work separately on enhancements and try to merge them into the latest revision when they're done.

I hope you're not counting on me to become part of the "team" so to speak and be regularly fixing and testing things, because I don't have the time or attention span for that. :p I just had some enhancement ideas and thought I'd see how well I could implement them, rather than just make another request for some obscure feature that ends up at the bottom of the priority list because I'm basically the only one who cares and the developers have more important things to work on.
 
E

ebenblues

Mupen64Plus Dev.
HyperHacker said:
OK, but say I find one bug, fix it, make a patch, find another one, fix that, won't the second patch have both fixes in it? How do I avoid that?
Click to expand...
You can submit all your changes in one patch and we'll sort through it. I don't think anyone's really going to be picky of any contributions. :) As others have said, if you're interested in contributing more long term, PM Richard42 and he'll give you svn access.
 
T

Tillin9

Mupen64Plus Dev.
I seen to have picked up Gtk programing rather quick, almost surprisingly as I was only taught on MFC and Qt3. I happen to have a number of Gtk GUI improvements on my todo list already, but sadly I'm swamped till Tuesday. Anyway... if you make some kind of list of the interface improvements you need / want , I'm definitely willing to spend some time further improving the GUI.
 
OP
D

DarkJezter

New member
Well, I resubmitted my changes to the trunk for the debugger, and that consists mostly of the fixes you've submitted already. Any other patches you'd like to include can be sent to me directly, and if they don't conflict with what I'm doing already, I'll include them in the debugger branch.

This way, you'll be able to generate diffs without patches showing up repeatedly.
 
You must log in or register to reply here.

Top