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

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Mittwoch, 31. März 2021 14:49:58 CEST Eero Tamminen wrote:

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

 

I can do that, but you should be able to use about any self-cmpiled code, just add debug information when compiling and linking.

 

>AHCC version probably works also with PC, after

>adding suitable PRJ file

 

AHCC does not produce the debug information that this patch uses. But IIRC, it uses at least the 22 name extension, so it might not be that critical. The main problem with Pure-C is, that a lot of symbols are ambiguous after being truncated to 8 characters.

 

 

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

 

They are already a bit different, mainly because the tool has some options which are basically hardcoded into the builtin command.

 

>it has been tested with GCC, VBCC, AHCC and Devpac.

 

At least for gcc, that does seem to be the case anymore. The values there are also relative to the start of the text segment (you can look at https://github.com/freemint/mintbin/blob/master/src/symbols.c which does not add any offsets, if i didn't miss it).

 

> => that thing should either have an option,or it should be auto-detected.

 

An option would be a bit confusing i think, since the user may not not whether to use it or not. But i have no idea how to auto-detect that, since you cannot assume that the symbols are listed in any particular order (and in fact, they aren't). The only thing that i can think of is to check for symbols in the data/bss segments with a value of zero.

 

>Latter would be required for adding this support to the Hatari

>debugger "symbols" command.

 

Yes, i feared that ;) The same fix is done there, too.

 

>I don't think the impact is that very user-visible

>(on PC) for other code.

 

Probably not. But it was easier to work with the offset to the buffer rather than have to think about how they have to be adjusted if only part of the file is in memory ;)

 

>Them sharing code [1], would be fine for me.

>Any such refactor should be separate patch though.

 

I'll try to come up with a new serious of patches that moves the common code first.