Re: [hatari-devel] Loading symbol info from program DRI/GST symbol table

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 06 huhtikuu 2013, Douglas Little wrote:
> I'll grab the new version and try this too - it will make things a lot
> easier.
> 
> BTW how best to deal with the labels-as-defines problem? Since the Hatari
> debugger takes the first label with a given address as 'the' label, this
> tends to pick the define versus the actual real label since defines tend
> to be at the top of a sourcefile.

This is the case just with the debugger.

The profile post-processor is slightly more sophisticated:

* When there are multiple symbol names with the same address:
  - It uses last name, unless it's an object file name (end=.o)
  - Unless name difference is just (max 2 characters) pre/postfix,
    it gives a warning about this replacement

* When there are multiple symbol addresses with the same name (e.g. libgcc
  function names for EmuTOS and normal program), it will add a postfix
  to the symbols to differentiate them.

One should always give symbols file to post-processor (when it's available),
even if profile data would already contain symbol names.


> If this is going to remain so, the only solutions I can think of involve:
>
> a) prefix all defines with some reconizable filtering term, and filter
> them out with some kind of rule (e.g. _def_blah)
> b) give defines a unique address by allocating memory to them (e.g
>  _def_blah ds.b 1; ...yuck)

I'm not completely sure of what you mean by "define".  Why they get
same adresses as real labels (and are marked for TEXT section)?


> Currently I have to edit the symbol table before importing, to get rid of
> these :-/ ideally the debugger/profiler would assume the *last* label
> with a given address is the nearest but I assume thats too hard to fix
> in the debugger.

Yes, because debugger cannot assume anything about the order of symbols
in the symbol file, it just reads and sorts them all (separately based
on addresses and on names).   "Correct" symbol is then just picked with
binary search.


	- Eero