Re: Libiberty demangling - new demangler - expected behaviour

[Ian Lance Taylor <iant at google dot com>]

"Phil Lello" <phil.lello@homecall.co.uk> 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:
> 
> DMGL_NO_OPTS
>  CTmProxyCore::CreateInstance
> DMGL_PARAMS
>  CTmProxyCore::CreateInstance(class CTmProxyCore * *,struct IUnknown *)
> DMGL_ANSI
>  static CTmProxyCore::CreateInstance
> DMGL_VERBOSE
>  public: static __stdcall CTmProxyCore::CreateInstance
> DMGL_TYPES
>  long CTmProxyCore::CreateInstance
> DMGL_RET_POSTFIX
>  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:
    http://www.codesourcery.com/cxx-abi/abi.html#demangler
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++
programs.

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.

Ian