Re: [hatari-devel] debugger help

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On perjantai 21 helmikuu 2014, Laurent Sallafranque wrote:
>> 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.

"symbols prg" uses the same host file name that was used by (succesful)
Fopen() to load the program binary, so the file name "should" already be
OK.

And the data is loaded from the Atari program binary, i.e. there shouldn't
be any newline conversions involved...

	- Eero

> 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
> > 
> > <mailto: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
> >     
> >     <mailto: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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/