linker wrapper

[Walter Bright]

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
>