Re: [hatari-devel] Little asm question

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 20 helmikuu 2013, Miro Kropáček wrote:
>> Then there's the question of whether one should support
>> DRI or a.out symbol tables?
> 
> I could easily live with DRI only, as gnu ld can produce both.

If you can provide minimal C-code (not just nm sources) for identifying
binary with such symbol table and printing the text section relative text
symbols from that, I could later try integrating its automatic use to
Hatari.

That should  be enough for most cases when one is debugging his own code.


>> And it of course doesn't work for stripped binaries.
> 
> That's clear, I could live with that, too :)

The main point of my verbose answer was that current symbols
command is anyway need. :-)


> The sad truth is that even
> in 2013, I still find the most convenient way how to debug some nasty bug
> to fire up Hatari, run Devpac's MON030 and check it out there.

I think that's fine, especially when debugging easier problems that
don't require tracing all kinds of system activity, DSP interaction
and/or higher interrupt levels.  While Hatari debugger has features
that MONST doesn't, even MONST2 has quite a few features not in Hatari
debugger yet (listed in Hatari's todo.txt).


> I simply can't use the Hatari debuger because of missing GUI,

Python GUI has *very* simple GUI for the debugger, to view memory
contents and disassembly.  I might some day rewrite the debugger GUI
in Qt/C++ as Python one is not responsive enough (and remove the one
from Python GUI).

GUI requires more code though, much more than the actual functionality
in the debugger currently, and it's not scriptable so that one could
automate its usage, so it's not so interesting for me...


> labels, complicated commands and everything. What makes me super
> sad everytime I read about its amazing features :-/

I think the only complicated command the debugger has is the one
for (conditional) breakpoints.  And the "immediate evaluation"
of things in quotes may also be a bit strange becase MONST uses
{} for the same purpose.


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).

To do tracing, you just list what you want traced, separated
with commas.  Syntax is same as for --trace command line option.

And to profile, you just enter "profile on" and continue emulation.
Whenever you re-enter emulator, you see profiler output.

All debugger commands have built-in help and TAB-completion [1]
for the subcommands.

I think the debugger manual is OK too.  You could browse it
quickly through to see what one can do with the debugger:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
file/tip/doc/manual.html#The_debugger


	- Eero

[1] For some commands TAB completion is incomplete.  If you get
    annoyed by some missing TAB-completion, just mail and I can
	look into adding that.