Re: [hatari-devel] Devpac symbol names in Hatari debugger?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 22 marraskuu 2012, Miro Kropáček wrote:
> yesterday I had the pleasure to code in m68k asm again and I realized
> that I still have temptation to better start Devpac/Mon than Hatari's
> debugger to check code/data. In the end I didn't need debugger at all
> but it raised a question in my head for the future -- is it possible to
> debug applications with devpac and/or a.out symbol names?

If you're asking whether Hatari supports digging out native Atari
debugging symbol information out from the binaries, the answer is no.

However, you can run "nm" (from binutils[1]) or "cnm" (from mintbin[2])
on them to get a list of symbols and their offsets in a binary, and ask
Hatari debugger to load & use that.  AHCC even has a separate option for
outputting the symbol information in "nm" format and Hatari tools/-dir 
includes script for converting AHCC's default symbol info to what Hatari
understands.

[1] http://sparemint.org/sparemint/html/packages/binutils.html
[2] http://sparemint.org/sparemint/html/packages/mintbin.html


Because Hatari debugger doesn't know anything about "programs", you need
to ask it to stop before the symbol info is needed, so that you can load
the symbols with correct offset.

Typically you load this info right at program startup. Following will
invoke the debugger at first program instruction:
	b pc = text  :once

And then loading the symbols with the program offset can be done with:
	symbols program.sym text

"text" is a virtual Hatari debugger variable that gives the text
section address from the current program basepage.  You should use
it only after TOS has booted because during bootup there's no basepage
(and emulator would complain about invalid basepage on every CPU
instruction) and it would also give valid looking values couple of
times during bootup (i.e. trigger debugger with above breakpoint).

":once" flag is used to make the breakpoint go away after it's triggered,
to avoid the above mentioned messages.

(These are explained in the Hatari manual debugger section.)


> I'm not that kind of person who can debug code without symbol names;
> then printf-like solutions work better for me.

There are several things you can do with Hatari debugger which AFAIK
aren't supported by any Atari debuggers or emulators, for example:
- printing out values in memory locations whenever they change
- tracing the symbol calls
- profiling the whole system

If the point of printfs is to find out what part of the code is
being run, the symbol tracing (potentially together with profiling
information) is IMHO better solution.  It tells about all calls
and doesn't require changing & re-compiling the program.

To get profiling information just for your program, not OS code,
you could just disassemble it if the amount of code is small.
With profiling enabled, disassembly includes profiling information:
	d text


If you use printfs to find about local (stack) data values,
then Hatari debugger is less useful as it's much harder to
find out those because you don't know where exactly compiler
puts those.  With function call arguments that is dictated
by the ABI though (last arg is on top of stack when entering
the function), but it's still annoying.


If you want to find out when some global variable value changes,
you can use this:
	b (name) ! (name)

If you don't want to enter debugger, just see the changes
e.g. during symbol tracing, make it a tracing breakpoint:
	b (name) ! (name)  :trace


I've never traced such variables though [3], so I'm not sure whether
one should use them with "data" offset instead of "text" one.
That would be unfortunately as currently multiple symbol files
cannot be used at the same time.

In memory, program text (code) section is directly followed by
data section which is directly followed by "bss" section. If
the program symbol addresses reported by "nm" are like that,
I guess using "text" section address as offset for everything
is fine.

(If not, I need to add some specific support for loading different
symbol name types with different offsets taken from the basepage.)


	- Eero

[1] Except for EmuTOS which provides this symbol info in a separate
    file, I've mostly dealt just with binaries without debug symbol
    info.