• Carl Sturtivant (22/22) Aug 20 2012 I've been looking at the objects etcetera produced by dmd, and
• Sean Kelly (35/49) Aug 20 2012 D's function demangle in std.demangle to decrypt some of the symbols =
• Carl Sturtivant (2/26) Aug 20 2012 Thanks, I'll do that. (Odd, my original post vanished from the
• Carl Sturtivant (1/10) Aug 21 2012 I submitted a ticket along these lines.
• Carl Sturtivant (7/23) Aug 26 2012 OK, so as a practical matter, I'd like to be able to demangle
• Carl Sturtivant (4/13) Sep 03 2012 Ah, just what I needed all along: this D ABI definition

"Carl Sturtivant" <sturtivant gmail.com> writes:

I've been looking at the objects etcetera produced by dmd, and 
using D's function demangle in std.demangle to decrypt some of 
the symbols found in such objects by nm.

http://sourceware.org/binutils/docs-2.22/binutils/nm.html

While demangle does produce a demangled version of some symbols, 
it does not in other cases where they nevertheless look as if 
they may be mangled names of some kind. I considered that perhaps 
they are C++ mangled names, but have been unable to get nm to 
unmangle them, even though it nominally knows about C++ name 
mangling.

Is there a better analog of demangle I can use to translate back 
some of these more intractable mangled names? I tried the one in 
core.demangle but it did no better. Or is there somewhere I could 
determine the demangling rules and implement them for myself? Any 
suggestions will be gratefully received.

Here are some examples that are not demangled by 
std.demangle.demangle :

_D13libd_demangle12__ModuleInfoZ
_D15TypeInfo_Struct6__vtblZ
_D3std5stdio12__ModuleInfoZ
_D3std6traits15__T8DemangleTkZ8Demangle6__initZ
_D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ

Sean Kelly <sean invisibleduck.org> writes:

On Aug 20, 2012, at 1:45 PM, Carl Sturtivant <sturtivant gmail.com> =
wrote:

 I've been looking at the objects etcetera produced by dmd, and using =

D's function demangle in std.demangle to decrypt some of the symbols =
found in such objects by nm.
=20
 http://sourceware.org/binutils/docs-2.22/binutils/nm.html
=20
 While demangle does produce a demangled version of some symbols, it =

does not in other cases where they nevertheless look as if they may be =
mangled names of some kind. I considered that perhaps they are C++ =
mangled names, but have been unable to get nm to unmangle them, even =
though it nominally knows about C++ name mangling.
=20
 Is there a better analog of demangle I can use to translate back some =

of these more intractable mangled names? I tried the one in =
core.demangle but it did no better. Or is there somewhere I could =
determine the demangling rules and implement them for myself? Any =
suggestions will be gratefully received.

std.demangle calls core.demangle, so it's no surprise that you got the =
same result.


 Here are some examples that are not demangled by std.demangle.demangle =

:
=20
 _D13libd_demangle12__ModuleInfoZ
 _D15TypeInfo_Struct6__vtblZ
 _D3std5stdio12__ModuleInfoZ
 _D3std6traits15__T8DemangleTkZ8Demangle6__initZ
 _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ

demangle is currently designed to demangle functions names, while the =
strings above are types.  During parsing, demangle sees the string as a =
qualified name and then expects a type, and when it doesn't find one it =
figures the symbol isn't valid.  It sounds like we either need a =
separate function for demangling types or if the demangle function =
encounters a 'Z' when it expects a type name it should realize it's =
demangling a type name, back up, and try again according to that logic.  =
I suggest submitting a ticket.

To learn how the demangler works, the easiest thing is to copy =
core.demangle into your workspace and compile a small app with it =
directly, turning on the debug info.  For example:

module abc;
import demangle_;
import std.stdio;

void main() {
	=
writeln(decodeDmdString("_D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demang=
le6__initZ"));
}

$ dmd abc -debug=3Dtrace -debug=3Dinfo demangle=

"Carl Sturtivant" <sturtivant gmail.com> writes:

 _D13libd_demangle12__ModuleInfoZ
 _D15TypeInfo_Struct6__vtblZ
 _D3std5stdio12__ModuleInfoZ
 _D3std6traits15__T8DemangleTkZ8Demangle6__initZ
 _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ

 demangle is currently designed to demangle functions names, 
 while the strings above are types.  During parsing, demangle 
 sees the string as a qualified name and then expects a type, 
 and when it doesn't find one it figures the symbol isn't valid.
  It sounds like we either need a separate function for 
 demangling types or if the demangle function encounters a 'Z' 
 when it expects a type name it should realize it's demangling a 
 type name, back up, and try again according to that logic.  I 
 suggest submitting a ticket.

 To learn how the demangler works, the easiest thing is to copy 
 core.demangle into your workspace and compile a small app with 
 it directly, turning on the debug info.  For example:

 module abc;
 import demangle_;
 import std.stdio;

 void main() {
 	writeln(decodeDmdString("_D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ"));
 }

 $ dmd abc -debug=trace -debug=info demangle

Thanks, I'll do that. (Odd, my original post vanished from the 
thread.)

"Carl Sturtivant" <sturtivant gmail.com> writes:

 demangle is currently designed to demangle functions names, 
 while the strings above are types.  During parsing, demangle 
 sees the string as a qualified name and then expects a type, 
 and when it doesn't find one it figures the symbol isn't valid.
  It sounds like we either need a separate function for 
 demangling types or if the demangle function encounters a 'Z' 
 when it expects a type name it should realize it's demangling a 
 type name, back up, and try again according to that logic.  I 
 suggest submitting a ticket.

I submitted a ticket along these lines.

"Carl Sturtivant" <sturtivant gmail.com> writes:

 Here are some examples that are not demangled by 
 std.demangle.demangle :
 
 _D13libd_demangle12__ModuleInfoZ
 _D15TypeInfo_Struct6__vtblZ
 _D3std5stdio12__ModuleInfoZ
 _D3std6traits15__T8DemangleTkZ8Demangle6__initZ
 _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ

 demangle is currently designed to demangle functions names, 
 while the strings above are types.  During parsing, demangle 
 sees the string as a qualified name and then expects a type, 
 and when it doesn't find one it figures the symbol isn't valid.
  It sounds like we either need a separate function for 
 demangling types or if the demangle function encounters a 'Z' 
 when it expects a type name it should realize it's demangling a 
 type name, back up, and try again according to that logic.

OK, so as a practical matter, I'd like to be able to demangle 
these types that appear as symbols in object &c. files. Is there 
a simple way I can modify a mangled type such as

_D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ

into a mangled qualified name so it can be demangled by the 
existing demangle function and the result then modified into a 
string representing a type?

"Carl Sturtivant" <sturtivant gmail.com> writes:

On Sunday, 26 August 2012 at 19:24:03 UTC, Carl Sturtivant wrote:
 Here are some examples that are not demangled by 
 std.demangle.demangle :
 
 _D13libd_demangle12__ModuleInfoZ
 _D15TypeInfo_Struct6__vtblZ
 _D3std5stdio12__ModuleInfoZ
 _D3std6traits15__T8DemangleTkZ8Demangle6__initZ
 _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ



Ah, just what I needed all along: this D ABI definition
http://dlang.org/abi.html
contains the exact definition of mangling.