Re: [hatari-users] nm style symbols

[Charles Curley <charlescurley@xxxxxxxxxxxxxxxxx>]

On Thu, 24 Dec 2020 12:20:22 +0200
Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

> 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:  

> 
> >> 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

Thanks, most useful. That also answers another question, which I now
need not ask.


> 
> 
> > 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?

One obvious one is a symbol of "0", which I actually have. If I try to
set a breakpoint on it with "a 0", the debugger, not unreasonably,
takes that as a breakpoint on the address of 0.

Otherwise, leading numbers don't seem to be a problem. I tested with
"0EQ", and that worked correctly. I haven't tried others. I remember
having a problem with a symbol with a number in it, but now I don't
recall what the symbol was.



> 
> 
> > 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).

A good idea. If I use the profiling, I'll keep that in mind.

> 
> 
> >>> 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)...

Ah, yes. Or consider a binary tree. It takes longer to load up, but
would be very quick to search. (I have no idea how you are doing it
now, so that may be out of order.)

> 
> 
> > 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?

I will if I need to. For now, the ASCII symbols get me what I want.




-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/