linker wrapper

Rainer Schuetze r.sagitario at gmx.de
Thu Nov 11 15:24:38 PST 2010


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?

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



More information about the Digitalmars-d mailing list