[hatari-devel] Debugger improvements
Eero Tamminen
eerot at users.berlios.de
Sun Feb 14 21:58:42 CET 2010
Hi,
Please check the notes about address breakpoints changes below
if you're using Hatari debugger!
On Saturday 13 February 2010, Eero Tamminen wrote:
> Actually, I'm going to allow expression anywhere in debugger with similar
> syntax. (haven't finished implementing it yet.)
This is done.
> > * Expression evaluation should support register, symbol & variable
> > names.
> >
> > Then you could do also things like "d a0+HBL" or "dd pc-8", not just "d
> > pc".
>
> The downside is that except for few exceptions[1], you need to give them
> in quotes. This is to be able to differentiate disasm & memdump ranges
> from subtraction operation. Upside is that you can use expressions for
> both ends of the range, like this:
> d "pc"-"pc+$20"
>
> Also, due to making expressions support register names (and symbols), and
> register names being similar to hexadecimal numbers, in expression all
> hexadecimal numbers need to be prefixed with $ or 0x. I.e. the number
> base setting will work for hex only outside of expressions.
Well, not all. One needs to add prefix only to hexadecimal numbers that
could be confused with registers (d0-7, a0-f7). Let's hope that's not
a problem.
> [1] evaluate command doesn't need the quotes. I could make dsp/address
> command not to require them either and always evaluate the address
> command argument, but this would mean that you would always need to use
> $/0x for hex numbers which could be annoying...
Address breakpoints won't require quotes for evaluation.
> > Note that parenthesis are used for precedence with the evaluated
> > expressions, they cannot be used for indirection. Parenthesis behaving
> > differently on expressions and conditional breakpoints could be a
> > source of confusion, but I don't see anything that could be done for
> > that.
>
> Any comments on these limitatations?
>
>
> After this is done, I've thought to remove the "value" command. Evaluate
> can do the same, better. Number base setting could be moved e.g. behind
> setopt command (I think it's more logical there).
Done, "value" command is gone.
> Setopt could have also options for setting how many lines disasm and
> memdump display by default. Should they be separate for each? What
> about DSP v.s. CPU memdump & disasm?
Any comments on these?
> > Some other things I thought I could add/change:
> >
> > * Removing the current address breakpoint implementation and
> > implementing them as shortcuts for conditional breakpoints. With
> > symbol etc support it's getting too awkward to support two separate
> > breakpoint
> > implementations (of which the address one needs more support for
> > having it both for CPU and DSP).
Done, address breakpoint is now just an alias for conditional breakpoint.
(adds <100 LOC, removes >300 LOC)
This is large change. Please check that "a" & "da" breakpoints still work
fine, I've tested them lightly.
From the usage point of view, the main differences are:
* Removing an "a" & "da" address breakpoint needs to be done using
conditional breakpoint command: "b <index>" as it's not possible to
identify conditional breakpoints by an address. You see the breakpoint
index when breakpoint is hit, so I don't think this is too much of
an issue?
* Breakpoint options require now ':', but it supports ":trace" as they're
now conditional breakpoints.
* DSP "address breakpoints" are now also counted
(you can use ":once" or ":<count>").
* You can give expressions as addresses ("a a+$200").
* Breakpoints in previously saved memory states are invalid.
(In long run it's better to save them separately, currently they're
still in the memory state file)
> > * Above change requires making the options in a way that makes then
> > easier to locate from a command. I thought to use ":" for this. Then
> > the breakpoints would look like this:
> > a $1234 : 4 # break on every fourth hit
> > b $ffaa ! $ffaa : trace # trace changes to value in $ffaa
> > b pc > pc : once # break after e.g. loop exits
Done.
> > * Adding "lock" option to the info command. This option would make
> > debugger to show the given info subcommand result whenever the debugger
> > is invoked. To make this more useful, I would add "registers", "disasm"
> > and "memdump" subcommands to "info" command. Then to see a certain
> > memory address whenever entering debugger (a breakpoint is hit etc),
> > one would use: info memdump $1234 : lock
> >
> > And to switch back to currently shown stuff (CPU PC, VBL etc):
> > info default : lock
>
> Done, with "lock" command.
>
> > * "until (u)" command to run until a certain condition happens:
> > u pc > pc
> > This would be just a shortcut for:
> > b pc > pc :once
> > cont
It's quite easy to do do shortcut wrappers for conditional breakpoints.
I won't implement them until there's been some discussion about what
would be most useful. If you have any wishes for shortcuts, please mail!
- Eero
More information about the hatari-devel
mailing list