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