This is the mail archive of the
mailing list for the binutils project.
Re: Libiberty demangling - new demangler - expected behaviour
- From: Ian Lance Taylor <iant at google dot com>
- To: "Phil Lello" <phil dot lello at homecall dot co dot uk>
- Cc: <binutils at sourceware dot org>
- Date: 01 Oct 2006 09:52:29 -0700
- Subject: Re: Libiberty demangling - new demangler - expected behaviour
- References: <000901c6e572$88c5ba90$0100000a@bigboy>
"Phil Lello" <email@example.com> writes:
> Before I go much further along this route, I just want to confirm that my
> planned implementation works the way (most) people expect it to. Please let
> me know if you disagree with my decisions.
> The relevant options (from demangle.h) for cplus_demangle are:
> #define DMGL_NO_OPTS 0 /* For readability... */
> #define DMGL_PARAMS (1 << 0) /* Include function args */
> #define DMGL_ANSI (1 << 1) /* Include const, volatile, etc */
> #define DMGL_VERBOSE (1 << 3) /* Include implementation details.
> #define DMGL_TYPES (1 << 4) /* Also try to demangle type
> encodings. */
> #define DMGL_RET_POSTFIX (1 << 5) /* Print function return types (when
> present) after function signature
> Using the mangled symbol
> - ?CreateInstance@CTmProxyCore@@SGJPAPAV1@PAUIUnknown@@@Z
> (from C:\WINDOWS\$hf_mig$\KB902400\SP2QFE\msdtcprx.dll)
> the OS decoded version (UnDecorateSymbolName in DBGHLP.DLL) is
> - public: static long __stdcall CTmProxyCore::CreateInstance(class
> CTmProxyCore * *,struct IUnknown *)
> So cplus_demangle output should be:
> CTmProxyCore::CreateInstance(class CTmProxyCore * *,struct IUnknown *)
> static CTmProxyCore::CreateInstance
> public: static __stdcall CTmProxyCore::CreateInstance
> long CTmProxyCore::CreateInstance
> CTmProxyCore::CreateInstance long
Well, no, not really.
DMGL_RET_POSTFIX exists purely for Java. You don't need to implement
it for C++ symbols. Although I suppose it will do no real harm.
DMGL_ANSI really exists to switch between an old g++ mangling scheme
and a slightly newer (but still quite old) mangling scheme which I
think was based on the C++ ARM. You should ignore DMGL_ANSI.
DMGL_TYPES should not affect the demangling of a complete symbol. It
exists to support demangling of types by themselves, as specified by
the __cxa_demangle interface:
If DMGL_TYPES is not set, and you see something which is not a
complete symbol, you should not demangle it. If DMGL_TYPES is set,
then you should demangle the type by itself. In your example above
you should certainly put the "long" in the DMGL_VERBOSE demangling; I
don't know whether you should put it in the demangling without
DMGL_VERBOSE. The g++ demangler will always demangle the return type
when it is available, but for g++ it is only available for template
functions and for function pointer parameters. It is not available
for ordinary functions or methods.
Your example for DMGL_PARAMS looks right: you should only demangle the
parameter types if DMGL_PARAMS is set. This is mainly a speed hack
for gdb. I think the issue is that gdb wants to call the demangler on
a large number of symbols at startup, but doesn't need to see the
parameter types at that time. Skipping the demangling of parameter
types led to a measurable improvement in startup time on large C++
That leaves DMGL_VERBOSE, which is really your choice. In the
GNU/Linux world, anything which gdb wants to see when setting
breakpoints on a function name should be displayed without
DMGL_VERBOSE. Anything which doesn't matter to gdb may be displayed
only if DMGL_VERBOSE is set; whether to require DMGL_VERBOSE or not
really depends on how useful the information is. In your example I
suspect that things like public:, static, and __stdcall are reasonable
to only display if DMGL_VERBOSE, but I don't really know enough about
MSVC to be sure.
Hope this helps.