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

[ Thread Index | Date Index | More Archives ]

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


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

I would suggest to raise the limit to 200 or so.

Just change these in src/debug/breakcond.c:

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.


Mail converted by MHonArc 2.6.19+