[hatari-devel] Hatari debugger improvements

Eero Tamminen eerot at users.berlios.de
Fri Jan 8 11:56:19 CET 2010


Hi,

Doesn't anybody have any comments on which of these you would
think the most important improvements to Hatari debugger?

For example the counting breakpoints should be easy to do, first
e.g. just for the address breakpoints...

On Sunday 27 December 2009, Eero Tamminen wrote:
...
> > with a built in window system,
>
> Things could even be shown on specific parts of the screen if Hatari
> dependency to ncurses is OK, but that could constrict the area for other
> outputs (help texts etc) and require changing a lot of code, so I'd skip
> that, at least for now.
>
> (I think that kind of stuff would be a better in a separate GUI debugger
> that works over the Hatari control socket.)
>
> > register locking,
>
> Hatari debugger already supports showing different kinds of invormation
> when entering the debugger.
>
> And what's shown when entering the debugger could be configurable (regs,
> memdump, disassembly, for CPU and/or DSP).  It could be based on
> the register values too (address in register N).
>
> The hard part isn't in implementing that, but getting a good syntax on
> how to specify it to the debugger...
>
> > search  in disasm mode, ...
>
> Byte search could also be implemented.  With an option for using word
> boundary for searching instruction opcodes.
>
> Doing it based on using assembler instructions (instead of opcodes) like
> is possible in Monst would probably be too complicated though, unless
> somebody wants to write the lookup tables needed for this...
>
> > I really used a lot of this some years ago and I don't see how adding
> > symbol to hatari debugger would make it much useful than debugging
> > directly under the emulated atari, there so much power in monst that
> > making Hatari at the same level would be a huge task.
>
> After digging my Devpac manual from the attic, I went through it and
> checked what other features Hatari debugger is currently missing in
> addition to above listed ones:
>
> 1. Showing PC and breakpoints positions in the disassembly output.
>    -> easy at least for PC and address breakpoints
> 2. Counting breakpoints.
> 3. Stopping at breakpoint only after it's been passed certain number
>    of times.
>    -> 2) & 3) are trivial to do too, but need to be done separately
>         for CPU, DSP and conditional breakpoints
> 4. Breakpoints that act only once (and disappears after a hit?)
> 5. Shortcut for telling to run until given (temporary breakpoint)
>     condition is hit.
>    -> Would be trivial to do after 4)
> 6. Running until code returns from ROM (exiting from super mode?)
> 7. Single stepping that skips Traps, Line-A, Line-F. And one that
>     skips also BSRs and JSRs.
> 8. Set breakpoint to next instruction and run (to skip loops)
> 9. Set breakpoint on specific OS call
> 10. Run slowly
> 11. Showing contents of memory pointed by the registers
> 12. Saving machine status to history buffer each time debugger is
>       entered (exception or breakpoint is hit) and being able to view
>       this history
> 13. SP & SSP as CPU register names (active & supervisor stack)
> 13. Fill and copy memory
>
> Although all together these are quite a lot of added code and complexity,
> each individual feature is pretty easy to do.  Which of them you would
> prioritize?
>
> (The hard thing would again be what kind of a syntax one would use for
> specifying them to Hatari...)
>
>
> Btw. Monst manual mentioned couple of things that could be nice in Hatari
> debugger.  For example:
> * Running until code gets out of ROM:
> 	SP = A7
> * Running until subroutine ends (RTS=0x4e75):
> 	(PC).w = 0x4e75  &&  SP > CURRENT_SP_MINUS_ONE


	- Eero



More information about the hatari-devel mailing list