[hatari-devel] start and break question

[Eero Tamminen]

Hi,

On lauantai 11 kesäkuu 2011, Nicolas Pomarède wrote:
> Le 11/06/2011 00:22, Eero Tamminen a écrit :
> > I'm not sure in which order the matching really should go (i.e. which
> > overrides the others), just that it should be same.   If loaded symbols
> > contain e.g. HBL or TEXT symbol, should value of that be picked instead
> > of Hatari variable value?
> 
> I think hatari's internal variable should have priority over any loaded
> symbol.

Ok, done.


> If a loaded symbol conflicts, either dismiss it (easy) or add an
> automatic suffix to it (_1, _2, ...) (little more complicated)

Good idea, I think former (+ warning when symbols are loaded) will be
enough.


> > Regarding expressions that the debugger parser evaluates, currently
> > they're marked with "", like in 'm "data"' above, but those would be
> > nice for indicating search strings too.  Should I change "" expression
> > markers to something else?
> > 
> > Rest of the debugger breakpoints&  expressions syntax already uses
> > these special ASCII characters: #!%&|():-_+*~^/<>=.
> > 
> > That leaves only these free: []{}?';
> > 
> > "'" character might be nice to leave for strings too, "m ?data?" looks
> > a bit strange and while "m [data]" looks IMHO fine, it's a bit more
> > complicated to write (on my Finnish keyboard) than above 'm "data"'.

After changing range parsing to accept regs, vars & syms, I guess it
won't be needed that often.  I think people mostly use just register &
symbol names in addition to numbers.

(I guess it's better to change these after v1.5 release?)


> > Any opinions on this?  There aren't many opportunities to change this
> > once the debugger starts to get wider usage...
> 
> Personnaly, I really don't like the "?" syntax ; I'd rather use {} to
> enclose expression ; it's not used in asm coding as far as I remember,

MonST uses {} for indirect addressing in its own expressions.
Hatari debugger uses () for that, similarly to disassembly.

> so it's the less likely to give a conflict with what the user is used to
> (better to add a completly new notation than to re-use a notation that
> has a different wide known meaning to the user)

Well, in expressions it might be nice to use () for changing precedence
instead of indirect addressing, but that would require using something
else than () for indirect addressing...

But I guess everybody's already gotten used to using () for indirect
addressing and doesn't need changing of operator precedence in expressions?


> As {} is also used in C or many other languages to delimit a block of
> code, I think it would also make sense to use this to enclose
> breakpoints' expressions/conditions.

So:
	b VBL = {VBL+4}
?


On lauantai 11 kesäkuu 2011, Nicolas Pomarède wrote:
>> Then I think conditional breakpoints would need to be re-designed
>> around / moved to address breakpoint code so that e.g. breakpoint for
>> pc=0 would signify the special case where condition should be
>> evaluated for every instruction.
> 
> In the case of expression used in breakpoints, I think they should
> always be run-time evaluated each time a breakpoint condition is tested.
>
> As I wrote in another thread I prefer the {} notation to add an
> expression/condition to a pc breakpoint (instead of the ?xxx? notation),

That thread was about marker for arithmetic expressions that will be
immediately evaluated when a command is entered by the user.

The ?foo? syntax was proposal for stuff that's evaluated whenever
breakpoint is checked at run-time.  Conditional breakpoints can already
evaluate registers[1] & variables at run-time, but they don't support
conditions with arithmetic operations being calculated at run-time:
	a0 + a1 + 4 = (a2) - 5

You can only use immediately evaluated arithmetic operations in them:
	b "a0 + a1 + 4" = "(a2) - 5"

(quoted parts are evaluated before the command itself is parsed i.e.
this works for all debugger commands.)
	

You need different identifiers for both of these evaluation modes
so that they can be differentiated and run-time evaluated stuff can
include immediately evaluated things if needed.



	- Eero

[1] Currently there's one difference between registers in conditional
breakpoints and in immediately evaluated (quoted) expressions.  For
former you can give indirect access width (byte/word/long) whereas
expressions currently use long access for indirect addressing.