Re: [hatari-devel] Using Hatari to debug custom version of EMUTOS

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 11/15/20 2:06 AM, migry wrote:
....
> So I bit the bullet and downloaded the sources for Linux. I have done 
> this quite a few times in the past with various amounts of success and 
> total failure, usually having a few issues to solve on the way. Getting 
> Hatari to compile was reasonable straight forward. I did have to 
> download some libraries, but I found a website which gave very helpful 
> instructions. Although I installed the "readline" library it was not 
> found by configure, nevertheless Hatari compiled and I was able to use 
> the debugging suggestions given by Eero.

Readline is needed only for debugger command line
history, editing and TAB completion. I.e. it's
useful only when directly interacting with Hatari
debugger.

On Debian based distributions (Ubuntu etc), you
need to install libreadline-dev package before
building Hatari.


> I have since read (on the other mailing list) that help not working 
> under windows is a known issue. In a later reply Eero suggested adding 
> the "-W" to the command line, and this did in fact work allowing me to 
> see the debug information running Hatari under Win10. Now the question 
> was how to redirect it to a file.

Hatari help shows option for that:
....
  --trace <flags>         Activate emulation tracing, see '--trace help'
  --trace-file <file>     Save trace output to <file> (default=stderr)

(There may be some things that still go to stderr
instead of specified file.  If you notice any,
please complain.)


On Linux you can direct command output to a file
by using ">" (for stdout) and ">>" (for stderr),
like this:
	hatari ... > stdout.txt >> stderr.txt


> Anyway under Linux I was able to generate the file of labels visited and 
> I used tkdiff to compare against a similar file created from my own 
> simulator. There were quite a few differences. Since I was using an 
> older version of EMUTOS I then started to "re-base" my code with all its 
> modifications, now based the EMUTOS v1.0 source. I have more or less got 
> back to the same place just in the past few hours. My simulator runs and 
> the code crashes starting up the desktop.

If you enable profiling [1] in debugger (after
loading debug symbols), Hatari will show you function call backtraces 
whenever you drop into
debugger [2].

You can also generate call graphs of what symbols
were visited between debugger invocations, see:
https://hatari.tuxfamily.org/doc/debugger.html#Generating_and_viewing_callgraphs


[1] Either by giving "profile on" command
interactively, or in the file given to Hatari
"--parse" option.

[2] Debugger ca be invoked with AltGr+Pause key
combo, or when a breakpoint you've set triggers
it.

Hatari processes keyboard input on next VBL, so
breakpoints are only way to trigger debugger at
some other points.


> Next is to compare the Hatari trace of labels with the trace from my own 
> simulator, to see where the code diverges, which should help me track 
> down the bugs which I have introduced.

Note that OS (EmuTOS etc) bootups aren't
100% deterministic.  There are small
variances when interrupts get called.

I assume this is because clock has slightly
different values at boot (due to Hatari
initializing emulated clock on boot from host
clock) and this affecting when interrupts
are started.


> I am sure I will have more questions about using the Hatari debugger in 
> the next few weeks. I have read the documentation and I have played 
> around, but it is a new set of commands to learn.


	- Eero