Improved Debugger

[AmigaBoy]

I've been using the new WinUAE debugger for a little while now, and I think it's great. Brilliant work Toni, and anyone that may have assisted I've come up with a mockup on how to improve it, in my eyes at least...

Basically, I want as much information available to me as possible. I'm used to the new way of debugging, where you have a disassembly, memory, stack, etc. all visible in realtime. WinUAE already does all of this, but everything's hidden unless you call the command (much like Action Replay, etc). What I'm suggesting is having everything on one screen, updated in realtime.
So for example, I'm sitting at 407CE. I press F10 (step over) or F11 (step in) and each of the windows is updated. I can also browse through memory or the disassembly simply by using the scrollbars. I find having to trace and browse one at a time extremely tedious.

Not shown in the screenshot is the stack which would be a nice thing to have somewhere as well, but I have no idea where to put it due to screen space.

Also as I mentioned, hotkeys would be great. F10 to step over, F11 to step in, F2 for (un)setting a breakpoint, etc.

Obviously anyone that wants the old school style of debugging can freely use the "Debugger CLI Output" section. The command line wouldn't be phased out as that gives a lot of power for other things such as the fa command, setting watchpoints, etc.

For those that have never used this type of debugger before, check out OllyDBG ( http://www.ollydbg.de/ ). Simply drag a Windows executable into it. It will load (if the file is compressed, it'll tell you, so ignore it for this test) and press F10 to step over (or F11 to step in). You'll notice that everything is updated.

I feel this would be a much more user friendly experience. This is of course, up to Toni. I support the quest for complete and precise A500 emulation much more than this idea, however should boredom strike, this can be a nice side project

Any other ASM types think this may come in handy or is it just me?

[AmigaBoy]

Whoops. I just realized that OllyDBG doesn't use F10 and F11 for tracing F8 is step over. F7 is step into. heh. It's been a while.

[BippyM]

I like this idea and think it would be an awesome improvement, though I know Toni hates gui development :/

[thor]

Hey Jason,

since Toni didn't post yet and I'm the one who did it with him, I hope you don't mind posting my point of view.

Thanks for your interest in the GUI debugger, nice to see someone using it. Actually it was your thread that made me thinking the powerful debugger could need a more powerful frontend than the console and start working on it.

First thing is that you need to remember this isn't OllyDbg nor OllyDbg for WinUAE, each has it's own requirements and philosophy behind it. And even if it would be like OllyDbg, there would be people asking why it isn't like <insert favourite debugger here>. So if something will be implemented there needs to be an interested developer and/or enough demand for a feature.

Originally Posted by Jason

Basically, I want as much information available to me as possible. I'm used to the new way of debugging, where you have a disassembly, memory, stack, etc. all visible in realtime. WinUAE already does all of this, but everything's hidden unless you call the command (much like Action Replay, etc). What I'm suggesting is having everything on one screen, updated in realtime.

You already have quite a lot of information always visible and when you only want to step through the instructions by looking at the diassembly (F5/F6), you usually don't need the output window and if you really need it you can quickly switch to it. Use one of the step commands and you can scroll with Alt+Up/Down/Left/Right. It is all updated when something changes, just not everything always visible and I don't know if it's really that necessary. Since the disassembly windows stay at the user entered (or PC at first call) location, it could be useful to make one window autoscrolling/add one autoscrolling window/add one small always visible autoscrolling window that shows disassembly around the PC.

Originally Posted by Jason

So for example, I'm sitting at 407CE. I press F10 (step over) or F11 (step in) and each of the windows is updated. I can also browse through memory or the disassembly simply by using the scrollbars. I find having to trace and browse one at a time extremely tedious.

Use something like the 't' command to step one or more lines and everything is updated. Of course, maybe there could be accelerator keys for some step commands so you don't have to type in command+enter, but honestly I don't care which keys OllyDbg uses. As for the scroll bars, I doubt they will be included. If you would let the system control the scroll bars you would need to set all disassembly/memdump lines which are far too many with the 32bit address range and it would be too slow. So you would need to fake it by setting only the visible lines and handle the scroll bars by the program. I have no interest in doing that. Another strong argument is that Toni doesn't like to use the mouse when debugging, so you would need to convince him (good luck ). For simplicity I had two buttons for scrolling, but he removed them and I think it's ok that way.

Originally Posted by Jason

Not shown in the screenshot is the stack which would be a nice thing to have somewhere as well, but I have no idea where to put it due to screen space.

You have the stack with some bytes (A7) always visible, so for a quick look it's probably enough, if you need some further investigation you can set the location for one of the mem dump windows (F3+F4) to the stack pointer.

Originally Posted by Jason

Also as I mentioned, hotkeys would be great. F10 to step over, F11 to step in, F2 for (un)setting a breakpoint, etc.

See above

Originally Posted by Jason

For those that have never used this type of debugger before, check out OllyDBG ( http://www.ollydbg.de/ ). Simply drag a Windows executable into it. It will load (if the file is compressed, it'll tell you, so ignore it for this test) and press F10 to step over (or F11 to step in). You'll notice that everything is updated.

For WinUAE dragging a file to the debugger will not be possible or useful, but something like a 'ft <taskname>' command may be useful, so WinUAE runs until the task is running. But I haven't investigated that yet, so I don't know if/when I or Toni will implement such thing. For the rest see above.

[Toni Wilen]

Most debugger features were added because they were needed for compatibility testing, it was never meant to be used for other things or being user friendly

I still use console version but updates and patches to GUI version are accepted.

[AmigaBoy]

Sorry for the delay in reply. Busy busy

Originally Posted by bippym

I like this idea and think it would be an awesome improvement, though I know Toni hates gui development :/

Thanks for the support BippyM. I'm a lot like Toni in that I hate GUI development too, so I understand where he's coming from. Nonetheless, I still think it'd be great to see these features

Originally Posted by thor

Actually it was your thread that made me thinking the powerful debugger could need a more powerful frontend than the console and start working on it.

I never thought I'd say it, but I'm glad someone found one of my posts useful

Originally Posted by thor

First thing is that you need to remember this isn't OllyDbg nor OllyDbg for WinUAE, each has it's own requirements and philosophy behind it. And even if it would be like OllyDbg, there would be people asking why it isn't like <insert favourite debugger here>. So if something will be implemented there needs to be an interested developer and/or enough demand for a feature.

I totally agree. I know while I'm used to OllyDBG, many Amiga users are probably used to the old school ways of Action Replay, Monam and the like.

Originally Posted by thor

Use something like the 't' command to step one or more lines and everything is updated. Of course, maybe there could be accelerator keys for some step commands so you don't have to type in command+enter, but honestly I don't care which keys OllyDbg uses.

The 't' command, as you said, is slow. An "accelerator" key in my opinion, would speed things up greatly.

Originally Posted by thor

As for the scroll bars, I doubt they will be included. If you would let the system control the scroll bars you would need to set all disassembly/memdump lines which are far too many with the 32bit address range and it would be too slow. So you would need to fake it by setting only the visible lines and handle the scroll bars by the program.

hmmm. I don't think it would be slow at all. Setting the visible lines is a good alternative and isn't difficult, but I'm not the one that would be implementing it

Originally Posted by thor

You have the stack with some bytes (A7) always visible, so for a quick look it's probably enough, if you need some further investigation you can set the location for one of the mem dump windows (F3+F4) to the stack pointer.

Yeah, but I often see values get pushed and popped off the stack, as well as many memory operations. It's extremely tedious to have to switch the memory window between A7 and another memory location, thus it would've been nice to have them both available

Originally Posted by thor

For WinUAE dragging a file to the debugger will not be possible or useful, but something like a 'ft <taskname>' command may be useful, so WinUAE runs until the task is running. But I haven't investigated that yet, so I don't know if/when I or Toni will implement such thing. For the rest see above.

No no. I didn't want to drag a file to the debugger I was giving steps on how to use OllyDBG to see a minimal example of what I'm talking about when I talk about the way OllyDBG handles debugging

Originally Posted by Toni Wilen

Most debugger features were added because they were needed for compatibility testing, it was never meant to be used for other things or being user friendly

Absolutely. I'm not picky. If that's all you guys need, then I won't complain. I'm glad the debugger has reached the point that it has. It's completely replaced ARIII and HrtMon for me already. What I posted were merely suggestions

Originally Posted by Toni Wilen

I still use console version but updates and patches to GUI version are accepted.

It took me over a week to post a reply to this thread so I don't think I'll be the one making any updates or patches to the GUI Of course, I hate Win32 & MFC coding in C/C++ anyway, so I steer clear of it (Win32 in x86 ASM on the other hand, I don't mind. I'm weird like that ).

Thanks for the comments and feedback guys! I'm still hoping that one day the debugger goes in the direction I outlined here, but really, if it doesn't, it's no big deal

[thor]

Originally Posted by Jason

Thanks for the support BippyM. I'm a lot like Toni in that I hate GUI development too, so I understand where he's coming from. Nonetheless, I still think it'd be great to see these features

I'm not ruling out the possiblity that some things will implemented in the future, but at least they're not on my current agenda

Originally Posted by Jason

I never thought I'd say it, but I'm glad someone found one of my posts useful

And I'm happy someone's using the GUI debugger

Originally Posted by Jason

The 't' command, as you said, is slow. An "accelerator" key in my opinion, would speed things up greatly.

Extremly easy to do, although I think these will not be F-keys since they are for switching the windows (any good idea?)

Originally Posted by Jason

hmmm. I don't think it would be slow at all. Setting the visible lines is a good alternative and isn't difficult, but I'm not the one that would be implementing it

Nor am I (no interest, scrolling with keys is good enough for me)

Originally Posted by Jason

Yeah, but I often see values get pushed and popped off the stack, as well as many memory operations. It's extremely tedious to have to switch the memory window between A7 and another memory location, thus it would've been nice to have them both available

Maybe someday And one need to find a good window layout where all the extra information can be put to.

Originally Posted by Jason

Thanks for the comments and feedback guys! I'm still hoping that one day the debugger goes in the direction I outlined here, but really, if it doesn't, it's no big deal

Maybe, we'll see. Thanks for your constructive comments. Personally I think the biggest problem of the GUI currently is that it's a bit slower than the console version. So any improvements in this area are most welcome. I still hope that other people can be encouraged to do something for WinUAE.

[AmigaBoy]

Originally Posted by Thor

Extremly easy to do, although I think these will not be F-keys since they are for switching the windows (any good idea?)

hmm. I've seen some debuggers use CTRL plus another key to step over/into/etc. Maybe something like that?

Originally Posted by Thor

Maybe, we'll see. Thanks for your constructive comments. Personally I think the biggest problem of the GUI currently is that it's a bit slower than the console version. So any improvements in this area are most welcome. I still hope that other people can be encouraged to do something for WinUAE.

I didn't know the GUI version was slower than the console, but that makes sense as there's more to redraw, etc.

I also hope others contribute to WinUAE. Just about every user bug Toni constantly for something, which is unfair to him. I myself have contributed to WinUAE years ago, but I don't think my code made it into the official distribution (as did many other "hacks" of that time). I don't have the time anymore, so I really do hope more developers step up and make this a joint effort (like other open source projects, such as MAME).

[thor]

Check next WinUAE beta

[thor]

Some user info for changes:

- F11 / F12 are shortcuts for 'z' and 't' commands respectively
- added disassembly and memory window to main (F1) window
- disassembly windows can be automatically set to current PC (option 'Auto set', shortcut Alt+A, F1-window is always set to PC)
- context menus for disassembly (copy+breakpoint functions) and memory (copy+set location) windows
- breakpoints shown graphically
- direction indicator for jumps/branches
- current instruction highlighted

Note: the instruction that is responsible for highlighting the changed values accidently ended up where it shouldn't be, so they aren't highlighted anymore and Toni released the beta before reading the mail, so either Toni updates beta 1 or wait for beta 2

[jotd]

Just a few words to say that I used the GUI version of the debugger to fix games using WHDLoad and I like it. Any extra improvements are welcome.
excellent work guys.

[thor]

Nice jotd, thanks. I wondered if anyone else is using the GUI.

There will be probably one other patch (in-place editing) for the 1.5.0 beta series. If someone has ideas/suggestions for further improvements, they are highly welcome, but probably won't do them soon due to time constraints.

[AmigaBoy]

Sorry I haven't posted yet. Real life and stuff...

I've given the new debugger a test run and it's unbelievably good! Having everything updated on one screen makes life so much easier. Thanks for putting in the time, thor. I had no idea anyone was even doing it
I do have a few suggestions. Whether or not they get implemented is no big deal. I think where's it's been taken already is a great step

First, a bug that occurs for me...
When I right click in the memory area and select "Set Top Address", the window is created off screen. It's still usable, but off screen.
Also related to that window is I can keep clicking "Set Top Address" and it'll keep creating those windows. Maybe just have 1? or make it modal so we can't do anything until the window is closed?


Now for suggestions...
- A minimize window button maybe? Noone else finds it annoying that they can't minimize the debugger window? I always have a huge window open to see more, so it covers my desktop.
- "Set Top Address" for the disassembly window too? Of course, pressing F11/F12 to step through will set the top address back to the current position however it would be nice to be able to view other disassembly.
- Scrollbars for the disassembly and memory window. A lot of times I like to snoop around and see what's around before I trace over instructions. As I said, F11/F12 would bring the focus back to whatever the disassembly is currently at. Maybe the memory window can stay at whereever we've scrolled to?
- When stepping through using F11/F12, how about it keeps the current screen of disassembly until it reaches the instruction below the bottom one, then it'll refresh with the next screen of disassembly. So for example, if I'm viewing C1BAAE up to C1BAD4 in the disassembly, when I step through, C1BAAE will remain at the top. When I step over C1BAD4, the new screen top becomes the instruction under C1BAD4 (eg. C1BAD8).
- For the disassembly (and maybe even memory window if possible), right click "Find All References To This Address"? I believe it corresponds to command fa
- Right click Breakpoints -> "List breakpoints". fl?
- Right click in the memory window and "Set value" to set a value for a memory address? Sort of like W C04397 35
- The ability to change the height of each of the sections. So I can make the disassembly larger than the memory window for example. I assume this one may be difficult since it looks like the debugger isn't using something like dockable windows right? oooh. Dockable/undockable windows....


I also have some general debugger improvements which I guess are directed more at Toni. I hope noone minds me hijacking my own thread
I loved the ability in AR3 to see where a function starts and ends. Any chance of seeing something like that? Maybe directly after each RTS/RTE/JMP/BRA/etc? So it'll look something like:

00C1BAAE 4a42 TST.W D2
00C1BAB0 6604 BNE.B #$00000004 == $00C1BAB6 (T)
00C1BAB2 4483 NEG.L D3
00C1BAB4 4e75 RTS.L
======================================================================
00C1BAB6 2003 MOVE.L D3,D0
00C1BAB8 2f0e MOVE.L A6,-(A7)
00C1BABA 2c6d 03d8 MOVEA.L (A5, $03d8) == $00c2b484,A6
00C1BABE 4eae ffc4 JSR.L (A6, -$003c) == $00c3679a
00C1BAC2 2c5f MOVEA.L (A7)+,A6
00C1BAC4 2600 MOVE.L D0,D3
00C1BAC6 7401 MOVE.L #$00000001,D2
00C1BAC8 4e75 RTS.L
======================================================================
00C1BACA 5257 ADD.W #$00000001,(A7)
00C1BACC 60cc BT .B #$ffffffcc == $00C1BA9A (T)
======================================================================
00C1BACE 6100 ff92 BSR.W #$ff92 == $00C1BA62
00C1BAD2 60d4 BT .B #$ffffffd4 == $00C1BAA8 (T)
======================================================================
00C1BAD4 6000 ff9c BT .W #$ff9c == $00C1BA72 (T)
======================================================================

With the D command, how about the option "must be different"?
Also with the D command, the ability to reset the search? Like the C command by itself, the D command doesn't seem to have this option (as far as I can see anyway).

Like I said, none of what I've suggested above need to even be implemented. I love what we have now and I appreciate the time everyone's put in. Great stuff!

Anyway, enough from me. I'm sure my annoying factor has gone up ten fold now. I'll shut up now

[thor]

Thanks Jason for your constructive comments.

Originally Posted by Jason

When I right click in the memory area and select "Set Top Address", the window is created off screen. It's still usable, but off screen.

Never had that, but I'll check.
Edit: The menu or the window where you enter an address?

Also related to that window is I can keep clicking "Set Top Address" and it'll keep creating those windows. Maybe just have 1? or make it modal so we can't do anything until the window is closed?

Noted

- A minimize window button maybe? Noone else finds it annoying that they can't minimize the debugger window? I always have a huge window open to see more, so it covers my desktop.

Yes, why not

- "Set Top Address" for the disassembly window too? Of course, pressing F11/F12 to step through will set the top address back to the current position however it would be nice to be able to view other disassembly.

Easy to do, so very probable

- Scrollbars for the disassembly and memory window. A lot of times I like to snoop around and see what's around before I trace over instructions. As I said, F11/F12 would bring the focus back to whatever the disassembly is currently at. Maybe the memory window can stay at whereever we've scrolled to?

Not interested (yet?), sorry

- When stepping through using F11/F12, how about it keeps the current screen of disassembly until it reaches the instruction below the bottom one, then it'll refresh with the next screen of disassembly. So for example, if I'm viewing C1BAAE up to C1BAD4 in the disassembly, when I step through, C1BAAE will remain at the top. When I step over C1BAD4, the new screen top becomes the instruction under C1BAD4 (eg. C1BAD8).

Should be easy, but don't know if I want that. What do others think?

- For the disassembly (and maybe even memory window if possible), right click "Find All References To This Address"? I believe it corresponds to command fa

Where should it output those, to the output window or a new popup window with those values?

- Right click Breakpoints -> "List breakpoints". fl?

Same question as before. Besides you have them listed in F7 window and breakpoints are show graphically when in current disassembly

- The ability to change the height of each of the sections. So I can make the disassembly larger than the memory window for example. I assume this one may be difficult since it looks like the debugger isn't using something like dockable windows right? oooh. Dockable/undockable windows....

Don't know, at least not anytime soon

- Right click in the memory window and "Set value" to set a value for a memory address? Sort of like W C04397 35

What about this (in-place editing as mentioned before)

[AmigaBoy]

Never had that, but I'll check.
Edit: The menu or the window where you enter an address?

The actual window.

I can't drag it into view either, however with it enabled, I'm able to enter the address and press ENTER or press ESC for it to go away.

Where should it output those, to the output window or a new popup window with those values?

hmmm. Good question. I think the output window would be fine.

Same question as before. Besides you have them listed in F7 window and breakpoints are show graphically when in current disassembly

Oh. I didn't know about F7. I haven't actually checked through the F keys yet Maybe also have them in the output window?

What about this (in-place editing as mentioned before)

That looks great. It seems like it'll be much quicker than a set value window. Will this also be available for the memory window?

Thanks thor!

[Toni Wilen]

Originally Posted by Jason

- When stepping through using F11/F12, how about it keeps the current screen of disassembly until it reaches the instruction below the bottom one, then it'll refresh with the next screen of disassembly. So for example, if I'm viewing C1BAAE up to C1BAD4 in the disassembly, when I step through, C1BAAE will remain at the top. When I step over C1BAD4, the new screen top becomes the instruction under C1BAD4 (eg. C1BAD8).

Stepping blindly? At least 2 following lines should be always visible.

With the D command, how about the option "must be different"?
Also with the D command, the ability to reset the search? Like the C command by itself, the D command doesn't seem to have this option (as far as I can see anyway).

Ds resets. "must be different" will be done..

[thor]

Originally Posted by Jason

The actual window.

I can't drag it into view either, however with it enabled, I'm able to enter the address and press ENTER or press ESC for it to go away.

Are you running WinUAE from Gamebase or something? Because when running from Gamebase I have the same problem (haven't checked why yet), otherwise it's fine here.

hmmm. Good question. I think the output window would be fine.
Oh. I didn't know about F7. I haven't actually checked through the F keys yet Maybe also have them in the output window?

Not sure I want that, because for example if you're at the F5 disassembly window and click at the option and unless you know that something is written to the output, it may look as if wouldn't do anything

That looks great. It seems like it'll be much quicker than a set value window. Will this also be available for the memory window?

Thanks. That's why I chose the in-place editing in favour of popping up a window. And yes, it will be for the memory window and data/address registers too.

[AmigaBoy]

Originally Posted by Toni Wilen

Stepping blindly? At least 2 following lines should be always visible.

Yeah, you're right. I guess it really only works if you have the scrollbars too. Well, either that or have the current PC centered, but that would just be confusing.

Originally Posted by Toni Wilen

Ds resets. "must be different" will be done..

Great. I didn't know about Ds since it's not on the help screen.

Originally Posted by thor

Are you running WinUAE from Gamebase or something? Because when running from Gamebase I have the same problem (haven't checked why yet), otherwise it's fine here.

ah. You're right. I am running WinUAE from Gamebase. When run normally, it works fine.

Originally Posted by thor

Not sure I want that, because for example if you're at the F5 disassembly window and click at the option and unless you know that something is written to the output, it may look as if wouldn't do anything

No problem. F7 does the job well

[eLowar]

Originally Posted by Jason

ah. You're right. I am running WinUAE from Gamebase. When run normally, it works fine.

Different resolution maybe? If you figure out why (if you indeed bother and try to find out), please let us know.

[thor]

Problem found. Wasn't my fault Has nothing to do with Gamebase.