Re: [hatari-devel] Profiler question

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 01 lokakuu 2013, Miro Kropáček wrote:
> I used the gst2ascii tool to export symbols but now I realized it was
> useless because the symbols are read from the prg itself :)

Note that there are (many) situations where you want to edit the symbols
information, especially for GCC builds as GCC puts to symbol table all kinds
of crap whereas recent MiNTlib builds strip useful symbols from the produced
library.  While this isn't issue for reading the profiler disassembly,
good symbol information is essential for good profiling *post-processing*
results (top CPU consuming functions list, callgraphs...).

Unlike Atari binaries, the ASCII files produced by gst2ascii are easy to
filter & modify. :-)


You also need gst2ascii when using the profiler data post-processor as
that Python script supports only ASCII symbols data.  IMHO the support for
reading symbols from the binary itself is most useful for adhoc debugging
of program behavior.


> > I don't think that means your code has 100% miss rate. It just means
> > the profiler was able to account for all of the misses which did
> > occur, based on cross-referenced sums. I'm sure you can ignore it (ask
> > Eero for details).

CPU side profiler gives summaries separately for RAM, Cartridge and TOS
memory areas.  100% number you saw means that all code that was executed
during profiling was withing single memory area.

The summaries are meant to give you an overview of whether only
program code was executed, or was it also calling TOS functions
/ were TOS interrupt handlers executing during profiling, and
how much code went though Hatari's GEMDOS trampoline in Cartridge
area.  This is interesting when debugging program that gets stuck.


> > It's certainly possible the symbols are not properly 'rebased' relative
> > to your text section. This will cause them all to have wrong addresses
> > (See my notes above).

Typically you set breakpoint to program start to load symbols at
that point.

When loading ASCII format symbols, you need to give their offset.
With TOS & DSP code that's not needed as they're loaded at fixed
addresses specified in the symbol table.  For programs you need to
give "text", "data" & "bss" offsets.

When you use "symbols" command "prg" shortcut, symbols are loaded from
the last executed Atari binary and text, data & bss symbol addresses in
it are automatically offset to correct program sections.


> There's only one suspicious things, some labels were too long (>22 chars)
> and reported to be duplicated (i.e. the same label would point to >1
> addresses).

This is a DRI format limit.  AFAIK it's best that Devpac offers.


	- Eero