Re: [hatari-devel] debugger help

Ok I might be speaking too soon here.. but..

...yes that is already awesome :-) A quick test over lunch with the patch applied proves that I can now trace through code in logical PC order using 'n' command alone, without having to figure out what each branch is going to do, or if it's a control-flow op like RTS.

Tracing just got 10+ times easier :) The pain is gone!

NB I also didn't notice any interrupts getting in the way during tracing, although I was running until a breakpoint rather than breaking in forcibly. I'll report on this separately after I've had some time to play with it.

Thanks Eero!

On 20 February 2014 21:23, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

On torstai 13 helmikuu 2014, Douglas Little wrote:
> I will give that a try, thanks! :-)

Does it work OK now?

(I'm wondering should I commit it to repo & document in manual.)

- Eero

> Doug.
>
> On 12 February 2014 21:05, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > Hi,
> >
> > On tiistai 11 helmikuu 2014, Douglas Little wrote:
> > > If "next" should behave like "next" in other debuggers, it would
> > >
> > > > need to know what the current instruction will do, and depending
> > > > on that, either set breakpoint like now, or step one instruction.
> > > >
> > > > Question is, what kind of instructions would require breakpoint
> > > > instead of stepping: BSR, JSR, BKPT, ILLG, STOP, TRAP....?
> > >
> > > I agree this is probably difficult/complicated to implement in terms
> > > of predicting a breakpoint address. It's probably more comfortable
> > > as a hook in the emulation stepper itself, which informs the
> > > debugger of each new PC visited and provides an opportunity to
> > > break. Something like that which doesn't require the debugger to
> > > understand a lot of detail on what happened - shoves the work onto
> > > the emulator.
> > >
> > > I don't know if that is something that fits well with Hatari and/or
> > > the existing cores - or what other side effects this would have on
> > > performance, if it could even be made optional etc. so that's
> > > another matter entirely...
> >
> > Does the attached patch do what you were after?
> >
> > (*_OpcodeType() functions have some deficiencies in them, but
> > those can be improved separately.)
> >
> > - Eero