[hatari-devel] Steem debugger features not in Hatari debugger

Eero Tamminen eerot at users.berlios.de
Tue Jun 7 22:32:07 CEST 2011


Hi,

On tiistai 07 kesäkuu 2011, Nicolas Pomarède wrote:
> >>>     - Stack content display
> >> 
> >> Should be in the "easy" section I think, it's just a dump of the
> >> memory before the value pointed by A7.
> > 
> > You mean it would be just:
> > 	m "a7"
> > ?
> 
> m "a7" will display bytes at a7 and more (incrementing). But when you
> want to display the stack you must decrement. For example do something
> like (don't know if this syntax works) :
> 
>   m "a7" - $20
> 
> Which would display the last 32 bytes before the content of a7

Ah, right, in that case it would be:
---
> m "a7-$20"-"a7"
- "a7-$20" -> $65a8
- "a7" -> $65c8
0065A8: 00 14 00 00 23 10 00 fc b4 60 08 02 00 02 00 fc   ....#....`......
0065B8: bf 3c 00 00 00 00 00 01 00 00 00 20 00 00 a8 28   .<......... ...(
---


> > Steem actually has one more thing not possible in Hatari:
> >       - Setting a breakpoint on an interrupt
> > 
> > Any suggestions how to best check for interrupt?
> > (I mean, how to express it in breakpoints syntax)
> 
> Each interrupt in calling Exception() in newcpu.c with and exception
> number and and exception source (cpu, mfp). Adding a condition on the
> expception number allows to catch any kind of interrrupt.

I guess it would need at least this in an appropriate place in
newcpu.c::Exception():
--------
    if (regs.spcflags & SPCFLAG_DEBUGGER)
        DebugCpu_Exception(nr, ExceptionSource);
--------

But the question is where in Exception() this should be added so that
PC, cycles etc are correct?


And should the DebugUI() calls elsewhere in that function be skipped
if breakpoint was hit as it could be annoying to get first a breakpoint
and then drop again to debugger on DebugUI() call?



> > (Only potential small usability downside from working through remote
> > API would be this 0.1s delay per view before it gets refreshed that I
> > mentioned earlier.)

Note: this may be just a Python issue, not remote API one.
These things definitely shouldn't be this slow.

(For sockets there's setsockopt() call with which one can specify socket
buffer size kernel uses, as for low-latency communication the 110kB default
is quite large, but I don't know whether there's similar issue for fifos.)


> I think this 0.1 delay would be really annoying when trying to fast
> scroll pressing page down for example in a memory dump window.

Oh, I didn't notice that functionality in Steem.

For fast scroll the UI of course should just skip things that it doesn't
have time to show and just update the address.  I think that should work
fine for memdumps.


But there's a problem for scrolling instruction dumps backwards, regardless
whether it's shown by remote or "local" UI.  How it knows from which address
to request the instruction dump as instructions have different widths and
you would need to decode the memory content to know that width?

(The UI definitely isn't going to have its own instruction decoder...)


> >> And a way to search for hexa/text in Hatari's RAM.
> > 
> > This needs a new feature in the internal debugger too.
> 
> I think it could be added rather easily in the current debugger?

Sure, the point was that currently there's no such feature.


> We could even add text string in the search pattern :
> 
> search 'tos ' $45 $18 'atari'

Yes, especially as that's supported both by Monst and Steem.

Although "" already having a special meaning in debugger
(evalating what's in quotes) could be a bit confusing for
the user... :-/


	- Eero



More information about the hatari-devel mailing list