[hatari-devel] Hatari debugger improvements
Eero Tamminen
eerot at users.berlios.de
Sun Jan 24 19:39:26 CET 2010
Hi,
On Friday 08 January 2010, Eero Tamminen wrote:
> 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?)
I just commited the first four features for CPU address breakpoints.
Note: that if you have no _address_ breakpoints, symbols aren't shown
in the CPU disassembly trace either.
Usage:
* Set a breakpoint that is deleted before it drops you to debugger:
address <address> 1
* Set a breakpoint that triggers only on each fourth hit:
address <address> 4
Laurent, would you be interested about counted breakpoints for DSP?
> > 5. Shortcut for telling to run until given (temporary breakpoint)
> > condition is hit.
> > -> Would be trivial to do after 4)
Only if 4) would be implemented for conditional breakpoints...
> > 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)
With feature 4), this would be easy to do too. Anybody want a "next"
command?
> > 9. Set breakpoint on specific OS call
> > 10. Run slowly
"slow <msecs to sleep between instructions>"?
> > 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
"fill <range> <value>", "copy <range> <address>"?
> > 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
Please prioritize, what's most useful for you?
(I do very little instruction level debugging myself...)
Btw. I think soon the debugger needs to split the help output to sections
like the Hatari command line options help does...
- Eero
More information about the hatari-devel
mailing list