|Re: [hatari-devel] breakpoint on CALL_SUBRETURN condition doesn't work ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 13/04/2014 21:16, Eero Tamminen a écrit :
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
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.
If you mean creating some kind of linked list, I don't think it would
affect execution speed ; just slightly when you need to add / remove a
breakpoint number 'n', because you need to walk the list, but that's not
a problem since this will always be faster that what you can type in the
debug console. What matters is the cost implied at each opcode.
As for using more than 4 conditions, I haven't used it yet, but when
debugging FDC for example and some non working game protections, you
might want to reach the point where some specific values are in the 4
FDC registers (track, sector, ...).
Such a breakpoint would already need 4 conditions, so if you want to add
a condition on PC for a certain case, then you're at 5.
Normal cases certainly don't require high number of breakpoints /
conditions, but when you need to debug complex emulation scenario this
can increase quickly when you look for the right combination to reach
the point where program is about to fail.
That's an arbitrary choice, maybe 32 will never be reached and we can
use less, but 4 really looks to low for me.