<p dir="ltr">On 2 Jan 2014 19:50, "Martin Nowak" <<a href="mailto:code@dawg.eu">code@dawg.eu</a>> wrote:<br>
><br>
> On 01/02/2014 06:38 PM, Iain Buclaw wrote:<br>
>><br>
>><br>
>> The D frontend will generate the mangled symbol (and its initialiser) as:<br>
>><br>
>> _D6mangle18runModuleUnitTestsUZb7Console6opCallMFxAaZSrunModuleUnitTests7Console<br>
>><br>
>> _DrunModuleUnitTests7Console6__initZ<br>
>><br>
>> Instead of the more desired:<br>
>><br>
>> _D6mangle18runModuleUnitTestsFZb7Console6opCallMFxAaZS6mangle18runModuleUnitTestsFZb7Console<br>
>><br>
>> _D18runModuleUnitTest7Console6__initZ<br>
>><br>
>><br>
>> Is this desirable? It makes demangling such symbols difficult.<br>
><br>
><br>
> I think we should ignore extern(C) when mangling nested symbols.<br>
> But we should obey the calling convention.<br>
> So according to <a href="http://dlang.org/abi.html">http://dlang.org/abi.html</a> it's UZb instead of FZb.</p>
<p dir="ltr">I should probably rewrite the message as I did it in an awful hurry. ;)</p>
<p dir="ltr">The main point was getting across was that in the normal scheme of mangling it follows the convention in a nutshell:</p>
<p dir="ltr">TypeStruct QualifiedSymbol (Int Symbol) ...</p>
<p dir="ltr">Eg:<br>
S6foobar5inner...</p>
<p dir="ltr">Should 'foobar' be an extern (C) function, then the initial string count is omitted.</p>
<p dir="ltr">Sfoobar5inner</p>
<p dir="ltr">Causing core.demangler to choke on it.</p>
<p dir="ltr">This affects the demangler I've written for gdb as it follows the same rules to parse the mangled string.</p>