Re: [Freemint-discuss] TOS symbol files (was: Disassembly of TOS 1.00 with Ghidra)

[Eero T. <oa...@he...>]

Hi,

On 4.2.2025 8.58, Thorsten Otto via Freemint-discuss wrote:
> On Dienstag, 7. Januar 2025 21:52:53 CET Eero Tamminen wrote:
>> => Could those TOS address & symbol names be provided as Hatari (= nm
>> format) symbol files, along with checksums for matching original TOS images?
> 
> For TOS 2.x/3.x/1.4 such maps already exist (as for example tos306de.map in
> the glue directory: https://github.com/th-otto/tos3x/blob/master/glue/
> tos306de.map) However those were generated automatically, and could need some
> cleanup for Hatari's purpose. So i would like to know how they should look
> like.
> 
> - they have some absolute symbols like SELECTED that are used in assemmly
> sources. I guess it is better to remove those?

Absolute symbols are not used for values in disassembly.  Only use for 
them would be in breakpoints for variable value comparisons, but it's 
really marginal use.  IMHO indeed it's better to remove them.


> - they also have absolute symbols for the system variables. Should those be
> retained?
> 
> - same for absolute symbols for I/O addresses.

Yes, those are useful.


> - there are some duplicates that should definitely be removed
> 
> - Also note that BSS starts at address 0, unlike normal program layout. Could
> this lead to problems?

It depends on compiler whether BSS addresses start from program start, 
or from BSS section start, and Hatari code should already handle that, 
so it should be fine.


> - there are some symbols from the VDI overlay area, that appear as absolute,
> but are actually BSS variables. However they overlap with other symbols.

It would be good for them to have correct type, as absolute symbols are 
ignored in several contexts, where data/BSS symbols can be used (e.g. 
for TAB-completion).


> - What about local labels from assembler code? Mostly they are from BIOS +
> VDI. Would it be better to remove them (for the profiler to work), or retain
> them to easier identify exact locations?

Labels for loops are actively harmful.

Profiler adds each encountered symbols to callstack, so labeled loops:
* Can slow down profiler a lot
* Distort accumulated call counts, making call count callgraphs less useful

As to other local symbols, I've rarely found use for them.  Once one has 
identified issue down to a function / subroutine level, it's rather 
obvious from profiler instruction counts how the code flowed inside 
given function.

=> Remove at least all loop labels, or all local ones if it's more 
convenient


> - TOS 1.00/1.02 have another difficulty: there are text symbols from BIOS/
> GEMDOS/VDI, followed by data symbols, then followed by text symbols from AES/
> DESKTOP. Could those data symbols confuse Hatari?

IHMO symbol files are best to be sorted by address.


	- Eero