[fpc-devel] Maximum symbol length -- answer needed

[nickysn at gmail.com]

On Sat, 2018-06-23 at 11:19 +0200, Sven Barth via fpc-devel wrote:
> Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
> > 
> > > > I would propose to switch all targets to use use ansistrings
> > > > for 
> > > > symbol names.
> > > 
> > > Is this the consensus?
> > > 
> > > Personally, if I had any stake in this, I would be against it. I 
> > > mean, FPC is already slower than DCC.
> > 
> > I doubt this is a major contributor to that fact (especially since 
> > implicit exception frames are disabled for the compiler binary, so 
> > ansistrings don't result in extra exception frames). Additionally, 
> > this hashing makes it impossible to provide debuggers with a
> > function 
> > to reverse-map function symbol names onto class/method/type-
> > overload, 
> > which is a pain.
> > 
> > In theory, you could probably add support to debuggers to ignore
> > the 
> > symbol names and have them concatenate the class name, method
> > name, 
> > and parameter types, reproducing all the same hashing done by the 
> > compiler, but in general debuggers don't do this for performance 
> > reasons (so you can set breakpoints without parsing the debug 
> > information of the entire binary up front). 
> 
> But aren't there output formats that do have length restrictions for 
> symbol names? I take it that ELF and PE/COFF won't be problematic,
> but 
> what about those used for OS/2, DOS, etc.?

The OMF object format (used by DOS and Win16) has a limit of 255
characters for symbol names. But since we have an internal linker for
i8086-msdos, we can invent an extension to the format, that allows for
longer names. With some additional work, it can even be made backward
compatible.

Nikolay