www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - demangling (Ubuntu 64bit 12.04, dmd 64bit 2.060)

reply "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
Aug 20 2012
parent reply 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=
Aug 20 2012
next sibling parent "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.)
Aug 20 2012
prev sibling next sibling parent "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.
Aug 21 2012
prev sibling parent reply "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?
Aug 26 2012
parent "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.
Sep 03 2012