This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] : Demangle _GLOBAL_[ID]_ differently.


I found that symbols that start with _GLOBAL_I_ (and _GLOBAL_D_)
are not _always_ followed by a _Z<encoding> part, but that this
part is actually an disambiguation part that was added by 
`get_file_function_name_long'.

A more correct way to demangle these symbols is therefore to
just leave that disambiguation part for what it is.

As a result, the demangler will more consistently always say:

global constructors keyed to <whateverhere>

instead of sometimes saying

  global constructors keyed to int arbitrary(GlobalObject*)

and sometimes not demangling it and saying

  _GLOBAL_I__Z9arbitraryP16WeakGlobalObject.._.._src_looks_like_file.ccKFkjjfG3


This patch does that.  Tested with 'make check' in libstdc++-v3.
Give me a green light and I'll commit it.


ChangeLog:

        * include/bits/demangle.h (demangle<Allocator>::symbol(char const*)):
        Decode symbols that start with _GLOBAL_[ID]_ differently: the
        trailing part ends with a terminating zero and is not necessarily an
        encoding.
        * src/demangle.cc (): Same.
	* testsuite/demangle/regression/cw-13.cc: Adjust for new output.

-- 
Carlo Wood <carlo@alinoe.com>


Attachment: 1.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]