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

Daniël Mantione daniel.mantione at freepascal.org
Thu May 18 21:35:58 CEST 2006



Op Thu, 18 May 2006, schreef Thomas Schatzl:

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

Hmmm.... Why do they get that long then?

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

The mangledname of a symbol is decided at definition of a symbol, it 
cannot be changed later indeed. The behaviour with and without -Cg should 
indeed be equal, but that should be no issue to implement. 

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

That is right, but the assembler is a speed critical component of the 
compiler. Obviously a Pchar is faster than ansistring, but will require 
rewriting a lot of code and the programming comfort will decrease a lot.
Making things fit shortstrings is by far the most attractive option.

Daniël


More information about the fpc-devel mailing list