Investigating code in WinUAE

[mcgeezer]

To be honest I'd be happy if you got rid of the gui because I sometimes type 'xx' by accident and it goes into it.

I find the cli absolutely fine and appreciate it very very much. The only thing that slightly annoys me about it is that it breaks into a huge window sometimes and I have to keep resizing it.

[Jobbo]

Originally Posted by Toni Wilen

This looks interesting. As long as it can work as a dll because I am not going to statically link some huge libraries

I don't think it's actually all that big, that's kinda the point.

Unlike garbage like the Qt library.

I've used a branch that allows panes to be pealed off the main window. It's pretty amazing how it all works without needing to add any extra code.

Anyway, I highly recommend it for any game dev UI work.

[Radertified]

Originally Posted by mcgeezer

To be honest I'd be happy if you got rid of the gui because I sometimes type 'xx' by accident and it goes into it.

And on the flipside, I'd hate to see the GUI disappear because I sometimes type 'xx' by accident and end up cursing at the console debugger

[demoniac]

Originally Posted by a/b

You know what's also -10? Its window's Y coord. It keeps crawling up every time it shows up until it finally gets under the taskbar (yeah, I have it on top, just like Amiga's screenbar) and you can't see D0/A0 any more.

This issue is very annoying to me as well.

[roondar]

For some reason, I've always found the text debugger to be harder to work with than the GUI one. It's probably because the GUI debugger shows several handy bits of information at the same time in the same window.

It's not the actual commands, I can work with text based commands no problem.

Then again, I probably should somehow transfer over to something like MonAm for debugging. Just not too sure how that would work if you kill the entire system in your program.

Is there a main/big thread about generic debuggers or MonAm? Don't want to get too far off-topic here

[mcgeezer]

Originally Posted by roondar

Just not too sure how that would work if you kill the entire system in your program.

it doesn't help, the system dies. What I do is have a directive which switches off all the system killing assembler. Then I can freely debug the routines - a lot of the stuff I do doesn't actually do any screen stuff anyway.

[jotd]

I used HRTmon on the A1200, and also used the built-in hrtmon in winuae, but I found the Winuae text debugger more powerful.

At first it was horrible because I didn't know the command syntax, and if you make a mistake, the parsing just ignores the command...

But I'm using windows 10 with a proper console, fast copy/paste, and that's pretty good actually. I can pre-record / generate debug commands (breakpoint / print value / go ...) to automate some debugging, then feed the output to a python script that generates code for me (did that for TFX emulated FPU instructions).

One annoying issue is that CTRL+C copies text ok, but if you haven't selected any text it breaks and quits WinUAE... argh...

Another issue is when debugging keyboard interrupts, if you type "g"+RETURN, the return key is intercepted by the amiga program... grrrr. To workaround that, I just copy/paste g+a linefeed from a windows console or a previous "g" command. Entering without pressing any key is easier: end+F12.

Also turn off JIT to be able to use memwatches.

A 100% reference guide would be handy. There are a lot of undocumented commands and options that I often forget. Only Toni knows them...

Best features:

- read/write/change memwatches. You can have this with whdload+hrtmon but it's limited and slows down the machine
- breakpoints that check program counter, not with illegal opcodes: means that you can put your breakpoint anytime, even if the code isn't already loaded there (also helps with on-the-fly decrypt routines that also check trace vector!!)
- trace without trace vector
- deep trainer, which requires a lot of memory but we have a lot of memory Invaluable.
- copper debug: you always know where the copper points to. You can also trace the copper (never used it)
- comprehensive disassembly, showing the values of the memory held/pointed by registers
- assembler too (a command)

[Radertified]

Originally Posted by jotd

There are a lot of undocumented commands and options that I often forget. Only Toni knows them...

The source for the debugger is always available. Just look for the "debug_line" function and read each of the cases for a complete list

Time consuming to read through trying to figure out exactly what each option is though. Still better than nothing. It doesn't have to be only Toni that knows

[aros-sg]

Btw debug feature idea:

Have a "flag array" for each emulated RAM address. A command in the debugger shall then tell the emulator that from then on it should flag each address that is being executed (whenever instruction is read from PC). Another command to tell the emulator that is should un-flag each address that is being execute. Another command to show the flagged addresses in debugger (or visually in GUI).

So then for example in a game you could play a level, use the flag-command in the debugger, scroll and play around in a level for some time, go to debugger and use the unflag-command, keep playing around in the level but this time without causing scrolling. After some time go into debugger and make it show the flagged addresses. Then you should get a quick hint where the code is that handles scrolling of the game.

[mcgeezer]

Originally Posted by aros-sg

Btw debug feature idea:

Have a "flag array" for each emulated RAM address. A command in the debugger shall then tell the emulator that from then on it should flag each address that is being executed (whenever instruction is read from PC). Another command to tell the emulator that is should un-flag each address that is being execute. Another command to show the flagged addresses in debugger (or visually in GUI).

So then for example in a game you could play a level, use the flag-command in the debugger, scroll and play around in a level for some time, go to debugger and use the unflag-command, keep playing around in the level but this time without causing scrolling. After some time go into debugger and make it show the flagged addresses. Then you should get a quick hint where the code is that handles scrolling of the game.

Hmmm the existing capabilities would be able to find scrolling code ( or any other code faster )

[jotd]

for code in chipmem there is a heatmap feature (vh). But the results are pretty obscure

What I would like would be a feature to show the number of times a location is executed, using blocks/grouping. I think that's heat map does but I really can't interpret the figures.

[mcgeezer]

First off I'd just like to say that I very much appreciate the work Toni does on the debugger, WinUAE is simply an awesome emulator and I love it.

If there's a feature request that I would like it would be for the ability to run a stack trace, especially useful for when symbols are available.

Even if it just reported which function it's going to land back into would be a huge benefit (at least for me).

[jotd]

stack trace is a fake easy thing to do. If you use stack to pass parameters, or LINK instruction, or saved registers, you have to know the stack frame structure (debuggers like gdb do that but I must admit I find that slightly magical) to know the callers.

you can dump raw stack, but saved registers will mix with calling addresses (+4 or +6 depending on BSR/JSR, this is also another issue)

[coldacid]

Why not just have some debugger wire protocol that can be used by another app for people who don't like the console? That way the debugger GUI can also just be removed entirely from WinUAE as well. That's how gdb frontends work. If anyone decides they do want to maintain the existing debugger GUI it can be done as an external project out of Toni's way.

[phx]

Originally Posted by jotd

stack trace is a fake easy thing to do. If you use stack to pass parameters, or LINK instruction, or saved registers, you have to know the stack frame structure (debuggers like gdb do that but I must admit I find that slightly magical) to know the callers.

Indeed! Although I have some experience with linkers and 68k-ABIs this is still a mystery to me. Even by analysing a 68k stack frame manually I usually have a hard time to guess the return address of the caller.
For other ABIs, like the PPC V.4 or PowerOpen ABI, this would be no problem, as the stack frame has a fixed format and each frame is linked by a pointer.

[mcgeezer]

i may be missing the point here but all the stack frame has to determine is which routine it is coming back to (call back from bsr/jsr). if one cant be determined then it’s assumed to be a parameter pushed onto the stack. Even that would be helpful for me.

[phx]

It's not that easy. There may be anything on the stack when you have a breakpoint somewhere inside a function. Parameters, saved registers, local variables, huge data arrays. In such a situation you have often no way to find the caller's return address by just looking at the stack.

The only solution would be when the 68k emulator tracks all sub routine calls in its own list and make them available to the debugger. (This still doesn't explain how the backtrace in native debuggers works.)

[Toni Wilen]

Originally Posted by coldacid

Why not just have some debugger wire protocol that can be used by another app for people who don't like the console? That way the debugger GUI can also just be removed entirely from WinUAE as well. That's how gdb frontends work. If anyone decides they do want to maintain the existing debugger GUI it can be done as an external project out of Toni's way.

a) It is almost certain there is no one that does it and also KEEPS MAINTAINING it. (see current GUI debugger)
b) Having stable API in emulator's debugger (that can do all kinds of weird things) is impossible.

stack frame tracking

uaedbg mode does it. Generic stack tracing is impossible due to multitasking.

[zenox98]

Download link from http://eab.abime.net/showthread.php?t=91321 doesn't appear to work any more.

[jotd]

@phx you can "guess" the stacktrace by first filtering out odd addresses, or invalid addresses (define "invalid" on a 32 bit system with a lot of memory banks enabled), custom chip locations, etc... That is something that I've implemented in some addition I made to a monitor plugged to Basilisk. But the app I was debugging was located in a given RAM area (8 MB) so it was easy to filter other addresses out

Note that it doesn't fix the case where a pointer on data is on the stack either. I guess that Toni doesn't want to implement some heuristic stuff that will never be right.