|Re: [hatari-devel] breakpoint on CALL_SUBRETURN condition doesn't work ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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:
#define BC_MAX_CONDITION_BREAKPOINTS 16
#define BC_MAX_CONDITIONS_PER_BREAKPOINT 4
To whatever you think appropriate. Have you hit the 4 condition
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.