Re: [hatari-devel] Little asm question

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On torstai 21 helmikuu 2013, Miro Kropáček wrote:
> Think of us, poor users! ;-) I'm not sure how powerful debugger GUI Steem
> has but I heard only praising about it. Maybe there's even no GUI, only
> very user friendly commands?

It has a GUI and it's pretty nice.  Features that Hatari debugger
is missing from STeem debugger are also listed in doc/todo.txt.


> > Trace and profiler functionality should IMHO be dead simple to
> > use and especially former is really useful in debugging (OS calls,
> > HW register accesses etc).
> 
> I must kick myself to look at it one day. As far as I remember, I
> everytime ended with the frustration about not knowing where's
> everything.

Hatari debugger is a system debugger, MON a program debugger.
That explains small part of the difference.


> In MON, you start the app, you see immediately its first
> instruction, nice labels, disassembled text segment with an arrow
> showing you "here you are!". And memory dump in a next window.
> In Hatari, I even don't know where to look if I want to stop it on the
> first instruction ;-)

But main difference is that debugger is "line" debugger,
it doesn't have any concept of screen to postion things
anywhere (else than on a new line). 

By default Hatari debugger shows you PC register value for both
CPU and DSP when you enter the debugger.

To stop at first program instruction, use:
	"b pc=text"

(But as explained, it can be used only after TOS desktop is up [1].)

If you want to see disassembly from current PC address, just
type "d".  Additional "d" commands continue from that address,
until you specify and address for it yourself.

To get symbols, disassembly and memory dump you can point
the above breakpoint to a file containing commands for these.
With "line" output, that can be a bit messy.


[1] One more way to work around this limitation about basepage
    content validity, is using following debugger scripts and
    starting Hatari with:
		hatari --parse setup.ini
---- setup.ini ----
# when first/next entering debugger load setup
lock file debug.ini
---- debug.ini ----
# on program startup, parse commands from given file
b pc = text :file program-start.ini

# get back to default debugger prompt
lock default
--- program-start.ini ----
# load program symbols
symbols mortar.sym text

# enable profiling and history
profile on
history on

# disasm first program instructions
disasm
--------------------------

When you first time enter debugger (after TOS desktop is up), breakpoint
for text address gets set up by the script bound to debugger invocation
with the "lock" command.

The referenced files (*.ini and mortar.sym) should to be in the directory
where you start Hatari, unless you use debugger "cd" command to change to
another directory, or give path for the files.

NOTE: for disasm command to use correct address, you need fairly recent
Hatari sources from repository as in earlier versions breakpoints were
not initializing debugger session (PC address for disassembly) for
parsed files.


	- Eero

PS. If you need extra variables in addition to ones already
provided by the debugger, those can be added.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/