Rainer Schuetze wrote:
Denis Koroskin wrote:
I suggested that previously [1], and I think that need to be a part of
DMD for a simple reason: some of the names can't be demangled because
their are somewhat "hashed" to avoid limitations such as long literal
name. E.g. "_D4math6Mбrix9х44F32__T3addTCЂ–ЎZЂ„ќFЂ—ќЂґЂ—".
This is not a "hashed" symbol, it is compressed and can be converted
back to the mangled string. The latest svn version of core.demangle has
a function to decompress it.
An example of a "hashed" symbol is
_D3dmd19TemplateDeclaration19TemplateDeclaration27deduceFunctionTemplateMatchMFS3dmd3Loc3LocC3dmECA03C220132A92B4B4768C252AA61AC
It cannot be fully demangled (though just demangling the symbol name
without type information should work most of the time and could already
be helpful).
I've seen dmd using a third way dealing with strings longer than 255
characters: instead of a single byte the length is encoded as 0xff 0x00,
LSB, MSB before the symbol characters.
Walter, is optlink able to deal with this 3rd representation in all
places, so we can get rid of those other two encodings?
The way long symbols on Windows are dealt with:
1. if they fit, they fit
2. try using the extended length method
3. try compressing the string
4. use a hash for the string
1..3 are reversible, 4 is not.
I was also considering adding the demangling to the build output parsing
of Visual D, but somehow didn't yet get to it. Please note that
sometimes mangled names are also used in error messages produced by dmd.
Rainer
