WinUAE debugger workflow: reset, disable breakpoints etc

[hop]

I'd be very grateful for some workflow tips. Often when debugging I have many breakpoints set that are hit continuously, and I'm debugging away. Then I want to restart the debugging process from the top (reboot the machine usually). The problem I have is that because the breakpoints are continually hit I can't access the WinUAE F12 menu to reset. I end up deleting most of the breakpoints, get access to the F12 GUI and reset, then enter the debugger again and put them all back in again. This is a bit tedious and error-prone.

I am hoping there are some better solutions that I've missed, such as:
1. Debugger "reset" or "restart" command
2. Debugger save/load state commands
3. Debugger disable/enable breakpoint commands
4. Something else I'm not aware of!

Thanks for any hints and tips.

[copse]

I was thinking that there must be tips myself, having started using the debugger for the first time yesterday.

I also had the the unable to reset because breakpoints were being continually hit problem.

[jotd]

There is no bp disable command. Personally, I tend to put the list of commands in a text file, then paste it.

for instance

f bp1
f bp2
....

paste it, then clear with "fd"

There's a limit of number of breakpoints though.

load/save states are also missing...

There's a cool feature: HH or H

H 100: from now on each time you type this you get the 100 last executed instructions

[hop]

Maybe going to have to get my hands dirty with the source.

I love H. Does it store instruction bytes or just PC?

[hop]

Originally Posted by jotd

There is no bp disable command. Personally, I tend to put the list of commands in a text file, then paste it.

Thanks for the tip. This is kind of where I'd ended up. Reassuring to know I haven't missed any features.

[a/b]

When I'm debugging my own stuff and have to fall back to winuae debugger, more often than not I use memory watchpoints instead of breakpoints. I put "tst.b $1111.w" in my code, and then in debugger "w 1 1111 1 r" to set or "w 1" to remove a watchpoint.

[jotd]

Originally Posted by hop

Maybe going to have to get my hands dirty with the source.

I love H. Does it store instruction bytes or just PC?

you need HH for that

Originally Posted by a/b

When I'm debugging my own stuff and have to fall back to winuae debugger, more often than not I use memory watchpoints instead of breakpoints. I put "tst.b $1111.w" in my code, and then in debugger "w 1 1111 1 r" to set or "w 1" to remove a watchpoint.

Yes, very useful as you can enable it when you want. I also learned about how to trigger a winuae breakpoint from the code.

osd_break:
	* sends a WinUAE command to enter WinUAE debugger
	.ifndef	RELEASE
	move.l	D0,-(a7)
	pea     0.w
	* Normally it would point to where the result of the command is written, but since the last parameter (first pushed)
	* indicating the number of bytes to write is 0, nothing is written.
	pea     0.w	
	pea     1003f-1002f
	pea     1002f(pc)
	pea     -1.w
	pea     82.w
	jsr     0xf0ff60
	lea     24(sp),sp
	move.l	(a7)+,d0
	.endif
    rts
		
1002: .asciz    "AKS_ENTERDEBUGGER 1"
1003:
        .align	2

you can probably send a lot of commands like those https://github.com/tonioni/WinUAE/blob/master/aks.def. Push params on the stack, get result in D0 or something. Documentation is not the strong feature of WinUAE

[Rock'n Roll]

To go back from WinUAE debugger to asmone for instance or to shell it is necessary
that all breakpoints are removed. And there is no special command for this.
There is also no command wd like fd, because wd is 'enable illegal access logger'
There is also no command that really list all breakpoints. (like GUI-Debugger, F7)

For this go sure all breakpoints are removed:

>f c72fc6
Breakpoint added.
>fl
0: PC == 00c72fc6 [00000000 00000000]

>f c72fce
Breakpoint added.
>fl
0: PC == 00c72fc6 [00000000 00000000]
1: PC == 00c72fce [00000000 00000000]

>f c72fc6
Breakpoint removed.
>fl
1: PC == 00c72fce [00000000 00000000]

>w 0 C72fd6 1
Memwatch breakpoints enabled
 0: 00C72FD6 - 00C72FD6 (1) RWI CPU
>w
 0: 00C72FD6 - 00C72FD6 (1) RWI CPU
>fl	
1: PC == 00c72fce [00000000 00000000]

>fd
All breakpoints removed.
>w
 0: 00C72FD6 - 00C72FD6 (1) RWI CPU
>w 0
Memwatch 0 removed

To many breakpoints are for my opinion not usefull.
A WinUAE reset is not neccessary. Test a program or investigate demo/game goes Shift+F12, g or x , next Shift+F12 and so on.
There are no problems. And then start the program again or make a start from savestate.

If I investigate a demo I make often a first view with the visual dma debugger >v-4
Then the next I watch the copperlist >o1
Sometimes it is usefull to go on the beginning of a frame. >fs 0 0
Also interesting is to find the call of a routine. So I make a >fi rts and find somthing like this: rts == $00011f72
Now I go back with: d $00011f72-10 (try,error to find the BSR bsr.w #$f82e == $0001179e) There are many ways to investigate.

[paraj]

Things I'd like (could do PR for them I guess):

1. Ability to read memory as part of expression, e.g.

f u32($6c)

to set BP at lev3 vector or

m u32(ra6+$a)

to see which library is in a6.
2. Running debugger commands from text file (more general than being able to save break points)
3. Reset command could be useful
4. Maybe some kind of stable interface to debugger to allow scripting/custom stuff? Would avoid bloating built-in debugger, and a couple of times I've modified WinUAE source code to e.g. profile some stuff (say number of chip reads or unimplemented int/fpu ops on 060 per frame).

Just dreaming though

[ross]

'reset' command is already in debugger (not from long time, but it's there)
Also in the variant 'reseth' and 'resetk' (hardware and keyboard)

[Toni Wilen]

Originally Posted by paraj

1. Ability to read memory as part of expression, e.g.

f u32($6c)

to set BP at lev3 vector or

m u32(ra6+$a)

to see which library is in a6.

Numbers are not a good idea because they can be too easily mistaken for parameters in parser.

Maybe something like this:

>m rl(rl(4)+10)
00FC00A8 6578 6563 2E6C 6962 7261 7279 0000 4AFC  exec.library..J.

>m rl(ra6+$a)
00FC00A8 6578 6563 2E6C 6962 7261 7279 0000 4AFC  exec.library..J.

(which is already done but not sure if this breaks something else. Possible read functions: RL/RW/RB)

2. Running debugger commands from text file (more general than being able to save break points)

Copy&paste it?

[jotd]

I'd love a comprehensive documentation of the debugger & command line options (besides the source code )

The memory indirection thing is for sure a great addition!

[paraj]

Originally Posted by Toni Wilen

Numbers are not a good idea because they can be too easily mistaken for parameters in parser.

Maybe something like this:

>m rl(rl(4)+10)
00FC00A8 6578 6563 2E6C 6962 7261 7279 0000 4AFC  exec.library..J.

>m rl(ra6+$a)
00FC00A8 6578 6563 2E6C 6962 7261 7279 0000 4AFC  exec.library..J.

(which is already done but not sure if this breaks something else. Possible read functions: RL/RW/RB)

Yes, that would be great. I don't think I've ever needed RW/RB, but maybe there's a sign issue. If you're adding general function anyway, maybe EXTB/W functions would be useful (or you could have ul/sl uw/sw etc). Could then do e.g.

d ra0+extb(rd0)*2

or whatever. However just being being to read a long in an expression is 99.9% of what I'd like to do.


@ross: Thanks, seems like reset commands were added this summer, didn't notice

[hop]

Originally Posted by paraj

@ross: Thanks, seems like reset commands were added this summer, didn't notice

Thanks! I must check I'm on V5.

[Toni Wilen]

Need better "function" support first. The way rl/rw/rb currently work is too messy.

[Rock'n Roll]

I have made on different places here sometimes good and sometimes less good suggestions for the WinUAE debugger.

Two more suggestions:
If dma-debugger is activated and I want investigate a rasterline or more, it would be good if
after a start on a certain rasterposition like >v $2c with every following >v the output on
the next position follows. In the moment it starts by 0,0 again.
So that every >v works the same way like >m, >d, >o.

and If I want enable the cycle-exact mode I have to leave the debugger: a command would be good like >ce and >ceo (on/off)

[Toni Wilen]

Originally Posted by Rock'n Roll

I have made on different places here sometimes good and sometimes less good suggestions for the WinUAE debugger.

Two more suggestions:
If dma-debugger is activated and I want investigate a rasterline or more, it would be good if
after a start on a certain rasterposition like >v $2c with every following >v the output on
the next position follows. In the moment it starts by 0,0 again.
So that every >v works the same way like >m, >d, >o.

Done. Was simple enough to do.

and If I want enable the cycle-exact mode I have to leave the debugger: a command would be good like >ce and >ceo (on/off)

No, this needs some more generic solution that would allow changing other options too.

[Rock'n Roll]

Thanks Toni!

One more idea: is it possible to display two different colours for the copper in the DMA debugger?
a dark yellow and a light yellow for Cop1 and Cop2 for example? and then change the colour to show if Cop1 or Cop2 is active?
It would be interesting for some copjmp cases.

[Rock'n Roll]

Ah, I see it's already there (at least roughly): vm shows three Copper channels:
3,0: 00eeee00 * Copper
3,1: 00aaaa22 * Copper
3,2: 00666644 * Copper

What are this three Copper channels?
3,0 COP1
3,1 COP2
3,2 ?

and with
>vm 3 0 00ffff00 ; changes color for all Copper
>vm 3 1 00ff0000 ; changes color COP 1 to red it's 3,0
>vm 3 2 0000ff00 ; changes color COP 2 to green it's 3,1
So, I can change the Copper color.

The order is a little bit strange because with the command for instance >vm 3 1 the answer is 3,0 and not 3,1:
>vm 3 1 00ff0000
3,0: 00ff0000 * Copper
>

Better would be:
>vm 3 00ffff00 ; changes color for all Copper
>vm 3 1 00ff0000
3,1: 00ff0000 * Copper
>

[Toni Wilen]

Different colors are for copper starting wait and copper doing bad things (COPJMP blitter wait bug).

I don't think copper pointer makes much sense in debugger because you can freely jump between pointers and they are only initial addresses anyway, it is not a copper state.