[hatari-devel] start and break question

[Nicolas Pomarède]

Le 11/06/2011 00:22, Eero Tamminen a écrit :
>
>
> Btw. Now that I looked, different places in the debugger check debugger
> variable, user symbol&  register names in different order:
> - breakpoint parsing: variable, register, symbol
> - expressions: register, symbol, variable
>
> 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?
>

Hi

I think hatari's internal variable should have priority over any loaded 
symbol. If a loaded symbol conflicts, either dismiss it (easy) or add an 
automatic suffix to it (_1, _2, ...) (little more complicated)

> --
>
> 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"'.
>
> 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, 
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)

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.


Nicolas