|Re: [hatari-devel] Patch to enhance symbol names of Pure-C executables|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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:
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
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
Them sharing code , 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
- 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
- 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
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
I would image that to have user-noticeable impact
only if one runs gst2ascii code on Atari (which