Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-05

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

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Thomas Schatzl

Hello,

From: Dani?l Mantione

Op Thu, 18 May 2006, schreef Thomas Schatzl:

Show quoted text 14 lines
> 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.

Show quoted text 11 lines
> 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

Reply by email

Daniël Mantione
to Thomas Schatzl

Op Thu, 18 May 2006, schreef Thomas Schatzl:

Show quoted text 14 lines
> > 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?

Show quoted text 6 lines
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.

Show quoted text 14 lines
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

Reply by email