[hatari-devel] Debugger improvements

Eero Tamminen eerot at users.berlios.de
Sat Feb 13 00:40:37 CET 2010


Hi,

On Sunday 07 February 2010, Eero Tamminen wrote:
> > Would it be possible to have this kind of command :
> >
> > d pc
...
> I gave this some thought and concluded that to do this properly, I would:
>
> * Use expression evaluation instead of checking just single symbol +
> number on:
>   - address breakpoints
>   - memdump
>   - disasm
>   The expression would be evaluated immediately

Actually, I'm going to allow expression anywhere in debugger with similar
syntax.   (haven't finished implementing it yet.)


> * 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.


[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...


> 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).

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?


> Some other things I thought I could add/change:
>
> * Evaluating expressions also for conditional breakpoints.  The
> expressions (register values etc) would be evaluated when the breakpoint
> is added (the result would be shown in breakpoint addition message).  I
> was thinking of using quotes ('"') for indicating which part of the
> conditional breakpoint should be evaluated immediately when
>   the breakpoint is added.

Done.

(implementation will change as I'll make it apply for everything in
the debugger)


>   For example to break when value in adress pointed by A0 matches the
> value currently in D0, one would use:
> 	(a0) = "d0"
> * 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).
>
> * 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

Not yet 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

To be done.


	- Eero



More information about the hatari-devel mailing list