Re: [hatari-devel] breakpoint on CALL_SUBRETURN condition doesn't work ?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 12 huhtikuu 2014, Nicolas Pomarède wrote:
> > (I'm wondering about whether I really would need at some point
> > add real support for simple breakpoints instead of having in
> > debugger just a shortcut command for defining simple pc=x
> > conditional ones.)

This would be mainly an internal change.

> Maybe this could be useful.
> Especially if could remove the ambiguity when you are in hexa display,
> but address must start with a "$" anyway.
> For example, "b pc=a1236" is rejected because it conflicts with register
> name I think.
> A shortcut for only setting an address breakpoint for PC could accept
> only address, not starting with "$" if base is hexa.

There is already "address" shortcut command for that. Just use:
	a a1236


> > Overhead is linear, and related only to number of active breakpoints,
> > not how many of them are available.  Every breakpoint is checked on
> > every emulated CPU & DSP instruction.
> > 
> > If there were real address breakpoints, cost of those for emulation
> > could be made logarithmic (by sorting the breakpoints after every
> > change).
> > 
> >> I would suggest to raise the limit to 200 or so.
> > 
> > Just change these in src/debug/breakcond.c:
> > #define BC_MAX_CONDITION_BREAKPOINTS 16
> > #define BC_MAX_CONDITIONS_PER_BREAKPOINT 4
> > 
> > To whatever you think appropriate.  Have you hit the 4 condition
> > limit too?
> > 
> > Tell if there's noticeable slowdown (e.g. for fast forward)
> > or CPU usage increase when you have 200 active breakpoints. :-)
> 
> If it take the same time to check for example 8 active breakpoint in a
> maximum list of 16 or 200 members, then I would even push
> BC_MAX_CONDITION_BREAKPOINTS to 1000 and maybe
> BC_MAX_CONDITIONS_PER_BREAKPOINT to 32.

On a 64-bit OS, above would be about 2+2 MB of BSS for CPU & DSP
breakpoints.

I don't think I've ever used more than 2 conditions.
In what kind of situation you would use more than e.g. 8?

If that large amount of them is (potentially) needed, it would be
better to change conditions and breakpoints to be allocated dynamically.
I looked at the code and that shouldn't have effect on the breakpoint
checking code / its speed.


As to the speed, you can test it with this:
-----------
ini=breaktest.ini;
rm -f $ini;
for i in $(seq 1000); do
	echo "b pc=$i" >> $ini;
done;
hatari --parse $ini
-----------
:-)


> What really matters for me is that when there's no breakpoint active at
> all the slowdown is minimal. If some breakpoint are added then the user
> is certainly more interested by breakpoint accuracy than by pure speed.

Right.


	- Eero