Re: [hatari-devel] Patch to enhance symbol names of Pure-C executables

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 30.3.2021 20.19, Thorsten Otto wrote:
> the attached patch tries to read the real names from the debug-information of
> executables compiled by Pure-C and (i think also PurePascal, if someone uses
> that). That should get rid of the annoying fact that the linker truncates the
> symbol names in the DRI symbol table to 8 characters (it does not even support
> the GST extension to 22 chars).

Could you provide a PC compiler binary with which that can be tested?

Minimal test-case I've used for checking gst2ascii
is Hatari NatFeats tester builds:
https://git.tuxfamily.org/hatari/hatari.git/tree/tests/natfeats

AHCC version probably works also with PC, after
adding suitable PRJ file.  Maybe you could you do
that and provide the PRJ file and resulting binary
with symbols?


> A few notes:
>
> - i've changed only the external tool (gst2ascii), but i think it can easily
> be adopted to src/debug/symbols.c

They should be kept as close to each other as
possible, to be able to compare them to each
other.

Them sharing code [1], would be fine for me.
Any such refactor should be separate patch though.

E.g. through "src/debug/symbols_common.c".

(Please add patch updating you to copyright and
authors.txt too.)


> - i had to comment out one line, that adds the section offset to the symbols
> value. I'm not entirely sure whether that is a bug in the tool, or in the
> Pure-C linker, but values in the symbol table generated by PLINK are all
> relative to the start of the text segment, not relative to the section they
> are defined in.

It's been there since the tool was added in 2013,
so I think it to be correct for most things
producing symbols, as at some point, it has been
tested with GCC, VBCC, AHCC and Devpac.

I think that some compiler (or assembler)
version(s) also didn't use section offsets,
but I don't remember which.

=> that thing should either have an option,
or it should be auto-detected.  Latter would be
required for adding this support to the Hatari
debugger "symbols" command.



> - It is a bit brute-force, by going through all symbols from the DRI symbol
> table, then trying to locate them in the debug info. That could maybe be
> optimized, but maybe it does no matter much (i've tried this with ORCS with
> debug information of ~1MB, and hardly noticed a difference)

IMHO symbols loading is fast enough that
performance doesn't really matter for it.

=> Simple code is much preferred over
   performance optimizations that make code
   more complicated.


> - you may still get truncated symbol names from linked-in libraries (unless
> those libraries also had debug information)

I think that's to be expected. :-)


> - since the debug format works a lot with offsets, i'm reading the whole file
> into a buffer and work with that. Maybe the remaining routines should be
> changed before calling that function, and do the same (currently they do a lot
> of seeking/single reads)

If they don't complicate the code, I'll accept
patches.

I don't think the impact is that very user-visible
(on PC) for other code. C-lib STDIO file access is
by default already buffered, so single reads hit
disk really rarely, which leaves libc call
overhead.

I would image that to have user-noticeable impact
only if one runs gst2ascii code on Atari (which
most won't).


	- Eero