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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 10 huhtikuu 2014, Nicolas Pomarède wrote:
> Le 09/04/2014 23:21, Eero Tamminen a écrit :
> >> I easily reached the limit by tracing through a game's
> >> protection, I think it could be raised to 200 or so.
> > 
> > What for you would need that many *active* breakpoints?
> > 
> > Just managing that large number of them is pain, listing
> > them would take many screens of output...
> > 
> > I typically use each breakpoint only once so I use ":once"
> > option for them, and I script debugging session with chained
> > breakpoints so that one breakpoint enables tracing of certain
> > things and next one disables them etc.
> 
> I needed to trace through a rather complex game protection, adding
> breakpoints one after the other,

You mean a case where you never remove breakpoints?

Are they conditional breakpoints or just simple address
breakpoints?

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


> with many subroutines, so 16
> breakpoints is not enough. If it doesn't add an exponential overhead

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


	- Eero