[hatari-devel] source level debugging with the Hatari debugger

Eero Tamminen eerot at users.berlios.de
Sun Jan 10 20:27:25 CET 2010


Hi,

Attached is patch to existing Hatari code and new files that add symbol
file loading, support for them for address (code) breakpoints,
TAB-completion for the symbol names, listing of loaded symbols
and a tester for the new code.

If it seems OK, I'll push it to the repo.

On Tuesday 29 December 2009, Eero Tamminen wrote:
> On Tuesday 29 December 2009, Mickael Pointier wrote:
> > >> and have symbols in the rom, in the program, etc... if you add the
> > >> possibility to add symbols from the debugger and then save them, you
> > >> can progressively start to comment the program you are debugging.
> > >
> > > What do you mean by "save them"?
> >
> > Well, imagine you try to trace some very nasty piece of program
> > (obfuscated driver, complicated protection; rom), some times you just
> > want to be able to add a symbol on the fly while you are debugging,
> > because you discovered the meaning of some code. Being able to save
> > these symbols in a text file you can reload later would be kind of
> > cool.
>
> I think it's better if you just add them to a file and then tell Hatari
> to (re)load that.  And if it's in a regular program you're running from a
> desktop, it may end up in another address, then you need on each load to
> give some offset for it.
>
> Btw.  I'm now thinking that the program offset could be actually
> something that's handled on the host side with some trivial helper
> scripts, Hatari debugger would be given just a list of absolute RAM
> addresses.  Debugger itself would support only one list of symbols at the
> time to simplify things (joining & offsetting the addresses can be done
> trivially with AWK, outside of Hatari).

Awk doesn't seem to handle hex numbers (the addresses).  Python would be
another possibility.  (I don't want multiple symbol file handling in Hatari,
it would spread eventually into configuration settings etc).


> > >> A real native debugger can also support non intrusive breakpoints,
> > >> breakpoints on data changes, conditional breakpoints that do not hog
> > >> the machine, etc....
> > >
> > > Hatari debugger already supports these features.  I added them to
> > > v1.3 with help from the others. (ideas mostly from Nicolas, and
> > > generic debugging support from Thomas).
> >
> > So much then for the "hatari debugger is far to be as advanced as
> > monst2"
>
> It's still lacking a lot of features that Monst2 has though.
>
> See my earlier "atari debugger improvements" mail.

Any comments on what features from that list would seem most important?


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symbols.diff
Type: text/x-diff
Size: 6347 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100110/929afe7b/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symbols-new.tar.gz
Type: application/x-tgz
Size: 3237 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100110/929afe7b/attachment.bin>


More information about the hatari-devel mailing list