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]

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


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