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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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


Nicolas