Re: [hatari-devel] debugger help

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 didn't spend time to look through the change history to see if this was actually modified since - but if not, it could perhaps point to some sort of problem with the host build type? e.g. CR/LF stuff?

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