This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bizarre symbol names generated by g++
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Paul Harman <paul dot harman at pa dot press dot net>
- Cc: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
- Date: Fri, 26 Sep 2003 10:26:46 -0400
- Subject: Re: Bizarre symbol names generated by g++
- References: <8F5C2C2217CFD71185230090279A655A1C4DD1@pax.panews.press.net>
On Fri, Sep 26, 2003 at 12:44:53PM +0100, Paul Harman wrote:
> Hi!
>
> These are probably very silly newbie questions, but I've been unable to get
> anything meaningful out of the mailing list's search engine...
>
> I'm having difficulties understanding the symbol names created by g++ when
> compiling C++ source code. I'm running g++ 3.2.1 on Solaris 2.8
>
> When I compile a simple function like this:
>
> bool render(node* aNode, struct gv__ContentItem &rendered);
>
> ... I don't get a symbol "render", I get this:
>
> _Z6renderP4nodeR15gv__ContentItem
>
> ...which is complicating my life a bit because I was hoping to use these
> functions in a dynamic library. dlsym() works okay if passed that label...
> but it's not a particularly pretty or understandable thing to look at!
>
> I've tried playing with various compiler options but haven't hit on a
> combination yet to make this string understandable. I presume that the
> weirdness is due to the necessity to have different symbol names for
> overloaded functions.
>
> I assume that the gibberish bares some resemblance to the function name and
> its arguments... if I had a way to determine what the symbol name was going
> to be then I'd be able to code to that. [I can spot the type names easily
> enough, but what do "Z6", "P4" and "R15" mean or imply?] Alternatively if
> there's a way to revert to 'normal' symbols, then I'd like to do that.
This is called "mangling". For GCC 3.x you can see how it works at:
http://www.codesourcery.com/cxx-abi/
On the other hand, a much better idea is to use dlsym with symbols in
an extern "C" block as the other answer to your question suggested.
Calling C++ functions is a bit tricky.
> This has also been causing me pain when I use gdb (v5.0) because it makes
> navigating around C++ stack traces difficult. Is there a more recent version
> of gdb that handles C++ better (for example doesn't keep saying "'this' is
> not an aggregate" when you try to do anything)?
Of course there is. GDB 5.0 predates GCC 3.x, or nearly so. Try the
GDB web site: http://sources.redhat.com/gdb/. Your best bet is a 6.0
snapshot, or waiting a few days for it to be released.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer