public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@cgsoftware.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: <gcc@gcc.gnu.org>
Subject: Re: DWARF-2 and constructors/destructors
Date: Wed, 05 Dec 2001 20:25:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0112052303400.9453-100000@www.cgsoftware.com> (raw)
In-Reply-To: <20011205230120.A12341@nevyn.them.org>



On Wed, 5 Dec 2001, Daniel Jacobowitz wrote:

> On Wed, Dec 05, 2001 at 10:52:46PM -0500, Daniel Jacobowitz wrote:
> > Suppose you want to call a (non-virtual) method in C++, from something
> > with Dwarf-2 info.  The only way to get the mangled name from the debug
> > info is DW_AT_MIPS_linkage_name.  This isn't, of course, present for
> > constructors/destructors, since the entry in the class definition is
> > for the abstract version.
> >
> > Is it reasonable for the debugger to have to mangle this itself?  The
> > constructor arguments can be arbitrarily complex.  Should there be
> > references in the debug information to the base and complete
> > constructors anywhere?
>
> And I see, in a rather memorable rant, Daniel Berlin saying that
> DW_AT_MIPS_linkage_name is "a hack" (certainly), "not necessary, and
> we're trying to make it go away anyway."

Yes, with which Jason Merrill agreed, IIRC. In fact, he first convinced
me.
:)
I'm just more vitriolic by a small margin.
> Dan, would you mind
> enlightening me on how to cope without it without having a full mangler
> for every supported C++ ABI attached to the Dwarf-2 reader?
Sure.
What exactly do you need mangled names for?
All the methods have real names anyway.
We already demangle them anyway when we lookup symbols, remember.

If you mean for calling constructors, it's abi specific.
Find all the matching constructors, which will be a small number, demangle
them, and pick the right one for your purposes.  The demangler actually
marks what type of constructor/deconstructor it is, the info is just not
propagated to somewhere where gdb sees it (in cp-demangle.c, it's stored
in the demangling_t structure, but we only hand back the string).

>
> As far as I'm concerned, GDB has no business ever mangling a single
> string.
Bingo.
>  Debug info should provide everything that we need.
Yes, it should.

Now go look at check_method_stub and gdb_mangle_name, and try to avoid
hurling.


>
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
>

  reply	other threads:[~2001-12-06  4:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05 19:53 Daniel Jacobowitz
2001-12-05 20:01 ` Daniel Jacobowitz
2001-12-05 20:25   ` Daniel Berlin [this message]
2001-12-06 10:39 ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.33.0112052303400.9453-100000@www.cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=drow@mvista.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).