[hatari-devel] Execution history debugger command
Eero Tamminen
eerot at users.berlios.de
Sun May 29 16:03:37 CEST 2011
Hi,
On sunnuntai 29 toukokuu 2011, Eero Tamminen wrote:
> On sunnuntai 29 toukokuu 2011, Nicolas Pomarède wrote:
> > A lot of things can be added to Hatari regarding debugging, but we
> > should stay consistent and focus mainly on emulation, I think the debug
> > functions we have are largely enough (unless we have some feedbacks
> > from users, which until there has not really been the case regarding
> > the debug part).
>
> That might be because Hatari hasn't had all features that native
> debuggers have (and because some people don't like using command line
> debugger)... :-)
And Hatari debugger not being "marketed".
(I've commented about it on EmuTOS & MiNT mailing lists sometimes when there
have been issues with which Hatari debugger might help, but I'm not on any
of the Hatari forums where demo coders visit...)
> > There's a lot of potential things that can be made, but if it's just at
> > the expense of code's growth and no one using it, I'm not sure it's
> > interesting to add them just for the sake of doing it.
>
> Well, I've actually been thinking of eventually adding most of Monst
> features to Hatari... History is one of these features (and it's on todo
> list).
Attached is a patch of what a fairly complete history implementation would
look like.
After that, the remaining missing Monst features (besides the UI & keyboard
shortcuts) are:
- Single stepping that skips Traps, Line-A, Line-F. And one that
skips also BSRs and JSRs. Run until RTS/RTE command
- Fill and copy memory command
- Search. For bytes or strings (Monst supports also searching
instruction (subsets), but that's a bit too much to do)
- Command to run slowly
(could also be Hatari shortcut, not just debugger command)
I can add them if somebody asks for them or when I need them myself.
- Eero
PS. Having debugger in Hatari also allows things that aren't possible in
native debugger due to their intrusiveness.
With the debugger input files and breakpoint parsing it's also easy to
automatically chain things, e.g. have one breakpoint that enables things and
another that turns them off. Native debugger is unlikely to be able to do
things like that, at least if it needs to read those commands from
files...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: history.diff
Type: text/x-patch
Size: 13173 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110529/042c219a/attachment.bin>
More information about the hatari-devel
mailing list