[fpc-devel] Re: fpc-devel Digest, Vol 21, Issue 32

[Thomas Schatzl]

Hello,

 >From: Dani?l Mantione <daniel.mantione at freepascal.org>

Op Thu, 18 May 2006, schreef Thomas Schatzl:
 >> Also assembler symbols/labels should get extended to strings > 255
 >>in the future because there is already a bug open in which it is 
 >>demonstrated that it is possible to create too long labels which makes
 >> a program uncompilable.
 >> Or some scheme derived which makes sure that labels never get larger
 >> than 255 chars.
 >> (Typed constant within 2 or 3 nested functions)
 >
 >This is exactly a thing that will not happen. Longer assembler labels
 >have no usefull advantage for the end user, they are only used
 >hidden from the user. Long names only cost memory. For mangled names, 
 >the compiler already switches to hashes instead of type lists. If there
 > is any other reason a symbol gets to long, it can be handled in a
 > similar way.

The compiler already hashes these symbols.

 > > Additionally even the ppc64 compiler isn't able to cycle when
 > > compiled with -Cg because of the shortstring limitation, a few
 > > symbols get truncated, which makes the assembler fail.
 > > This is because the assembler syntax for declaring a symbol in the
 > > GOT on this platform requires the compiler to add the symbol name
 > > twice to the directive. This effectively limits symbol names to
 > > around 120 chars already. Which is, as mentioned before, already not
 > > the case for the compiler as it is.
 >
 >The solution is to generate shorter symbols. Hash the symbol name if it
 >gets too long.

Hashing is already done in the compiler for these symbols.

And I think at that point in code generation it isn't possible anymore 
to change the symbol name. But I think I'd need to change the symbol 
name itself... what if that symbol is referenced by different places 
with different methods? Once with -Cg and once without... (Admittedly I 
haven't checked that).

Note that this symbol is not the "worst" one - there is one in the FCL 
(iirc) which gets even longer and made problems when the compiler 
internal hashing is done more aggressively (e.g. tweaking the hashing 
code of the compiler so that the make cycle succeeds, by roughly 
*halving* the compiler threshold for too long labels so that it starts 
hashing earlier)
Maybe there are even worse ones, didn't bother trying to make hashing 
even more aggressive.

I.e. there is _already_ existing code that produces such long labels, 
especially for things like VMT entries, interface stubs etc. That's why 
it doesn't require too much work to construct a non-compiling example 
(Note that I don't think that exactly those are affected by -Cg ;)

Additionally I didn't say that ansistrings have to be used for these things.

Regards,
   Thomas