Re: [hatari-users] nm style symbols

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-users Archives ]


Hi,

On 12/23/20 9:38 PM, Charles Curley wrote:
On Wed, 23 Dec 2020 12:43:23 +0200
Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
On 12/23/20 2:44 AM, Charles Curley wrote:
I would like to use an ASCII symbol table for a program I am
working on in Hatari. I am reading the manual, but it doesn't cover
everything. https://hatari.tuxfamily.org/doc/debugger.html

Which characters are legal in symbol names? It appears Hatari does
not like semicolons or parentheses.

No compiler or assembler accepts those in symbol
names either.

Mine does, which is why the question came up.
https://github.com/charlescurley/realforth

If I remember right, symbol names match pattern:
	[a-zA-Z0-9_.]+

Actually:
	[a-zA-Z0-9_.-]+

See:https://git.tuxfamily.org/hatari/hatari.git/tree/src/debug/symbols.c#n891


It seems to accept [0-9], but trying to set a breakpoint on some of
them causes problems, so effectively those are also out.

Could you give a concrete example of what fails?


Otherwise, that agrees with my experience.

I now have a shell script that substitutes two letter sequences for
unaccepted characters. Awkward, but it should work.

When doing profiling, I sometimes use scripts also
to remove some symbols that mess up profiling
(profiling is faster and you get better profile
info if you remove loop labels).


The documentation mentions creating symbols by hand. How does one do
that, and how does one then preserve such symbols?

You just write the file in some text editor
and load that in debugger.

Ah. I was thinking there was a way to define symbols within the
debugger. This works.

Symbols are in a fixed sized array to speed up
binary searches done during profiling.

(Symbol addresses are used to indicate which
addresses profiling tracks.  These checks need
to be done on every instruction during profiling,
so speed is critical.)

One could of course re-alloc the symbol table,
but I think doing that for each new symbol could
easily fragment memory, so I haven't added support
for that yet, as then one would need to support
also saving the symbols (either as absolute, or
relative to program address etc)...


I now have a lot of what I need to generate an ASCII symbol table at
compile time.

Have you thought of generating the standard DRI
symbol table for the binary, like Atari specific
compilers and assemblers do?


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/