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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/04/2014 22:32, Eero Tamminen a écrit :

> You mean a case where you never remove breakpoints?
>
> Are they conditional breakpoints or just simple address
> breakpoints?

hi,

These were simple PC breakpoints that I don't remove, because I need to 
monitor the changes during a loop.

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

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.


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

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.

Nicolas