This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Demangler woes with current CVS and type names
- From: Daniel Berlin <dan at dberlin dot org>
- To: Phil Edwards <phil at jaj dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 29 Jan 2002 23:31:01 -0500 (EST)
- Subject: Re: [PATCH] Demangler woes with current CVS and type names
On Tue, 29 Jan 2002, Phil Edwards wrote:
>
> Possibly I'm missing something obvious. Either way, g++ is emitting names
> which c++filt can't demangle. The problem is mentioned in libstdc++/2921.
> So from here down to "SUGGESTION" is just me rambling aloud; corrections
> welcome.
>
> At the top if cp/mangle.c, there is a comment:
>
> Additionally, g++ uses mangled names internally. To support this,
> mangling of types is allowed, even though the mangled name of a
> type should not appear by itself as an exported name. Ditto for
> uninstantiated templates.
>
> Except that mangled type names /do/ appear by themselves, in typeinfo
> objects. For any expression or type, "(typeid (foo)).name()" produces
> something which cannot be fed to c++filt.
>
> We get the "bad" symbol because tinfo_name() calls mangle_type_string(),
> which doesn't emit '_Z' at the start of the mangled symbol.
Then it's not a valid mangled symbol.
Period.
>
> My testcase:
>
> #include <stdexcept>
> #include <typeinfo>
> #include <iostream>
>
> struct whackamole { };
>
> int main()
> {
> std::cout << std::bad_alloc().what() << '\n';
> std::cout << (typeid (whackamole)).name() << '\n';
> }
>
> When run, this prints "St9bad_alloc" and "10whackamole". All good.
>
> Unfortunately, without the magic prefix, we can't go backwards:
>
> % ~/build/install-2002-01-28/bin/c++filt St9bad_alloc 10whackamole
> St9bad_alloc
> 10whackamole
> % ~/build/install-2002-01-28/bin/c++filt _ZSt9bad_alloc _Z10whackamole
> std::bad_alloc
> whackamole
> %
>
> It's not a mangler bug: the symbol appearing in the .o file is prefixed
> with _Z, but the string returned from type_info's name() is not. The ABI
> specifies the object file symbol name, not AFAICT the name() string.
The ABI says it should return a mangled name for the type.
Without the _Z, it's not a mangled name.
>
> At the demangler end, however:
>
> It looks like two semi-competing demanglers are in use: one in
> libiberty/cplus-dem.c, which looks to be an older one capable of demangling
> various schemes from other platforms, and another in libiberty/cp-demangle.c,
> which seems to be the new IA64 ABI one. The old one has been patched to
> call the new one.
Correct.
>
> Both of them can be built into a standalone demangler, but c++filt is
> being built from the old one. The new one is never built standalone.
> (Bit of a pity, it looks like the new one can give more info.)
Correct on both counts.
>
> Neither standalone demangler "works" here: the old one is demonstrated
> above, and the new one checks for a leading _Z in main() before calling
> the various subroutines. The newer subroutines can figure it out, though.
>
>
>
> SUGGESTION: we make the older demangler stop checking for _Z prefixes,
Whoa there.
Checking for _Z is always valid. Any valid new mangled name begins with
_Z.
The grammar quite clearly says:
<mangled_name> :: = _Z <encoding>
The ABI says the name() member returns a "mangled name".
Thus, it must begin with _Z.
If this is not intended, the wording *definitely* needs to be changed in
the ABI, because i can't find a way to read it that says it's okay to omit
the _Z.
While the hyperlink points to the type encoding section, the wording
implies it's a mangled name, not a "type encoding".
If they mean type encoding, someone should change it to read "the name()
member function ... containing the encoded name of the type".
--Dan