Re:D’s Newfangled Name Mangling
by cryptonector on Wednesday December 20, 2017 @06:06PM
(#15974707)
I don't understand why mangled symbol compression is needed. Sure, you need to demangle it for debugging and such, but... all you need is a lookup table, and then you can just hash them down. Yeah, then you need that extra metadata, but with mangled symbols you have it anyways. Hashing + lookup seems much less error prone.
[ Parent
| on HN ]
Re:D’s Newfangled Name Mangling
by klickverbot on Wednesday December 20, 2017 @07:01PM
(#15975095)
There are some advantages to having access to a human-readable representation for the symbol name, for example because not every piece of binary tooling out there necessarily also supports reading debug info for the target platform in question.
However, another benefit of this is simply that even if you can hash a huge string down to a fixed length, you still need to construct your huge string in the first place during compilation.
With D generally being quick to compile, by the time your symbol names were in the megabytes, all the string creation and manipulation could take up an appreciable fraction of the total compile time. (No kidding – I was quite surprised to see this show up on the profiles as well.)
Because the pathological case was IIRC exponential in length range.chain.opertion.length and idiomatically D's `n` in those chain length is very large, sometimes large enough to crash `nm`. The compiler based on LLVM does support hashing the trailing portion of the symbol.
You also need symbol names for linking.