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] | |
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] |