Re: [hatari-devel] debugger help

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi all,

> BTW I have noticed this version of Hatari (Cygwin build from the patched version) will happily read symbols from BMVIEW.TTP using 'symbols prg' whereas the older v1.7 native build for Windows will not. 

I think this "read symbols" options works well under "unix" systems but not under windows and I'm pretty sure that the '\' or '/' character is the problem here.
Hatari gets the "file" string from the TOS (formatted with \), and Linux systems enjoy it. But windows prefers '/'

I hadn't time to verify this, but I'm quite sure this is the problem.

Regards,

Laurent


Le 21/02/2014 14:57, Douglas Little a écrit :

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!

D

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