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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
