From: Jason Merrill <jason@redhat.com>
To: gdb-patches@sources.redhat.com
Cc: gcc@gcc.gnu.org, Jason Merrill <jason@redhat.com>
Subject: Re: [RFA/stabs reader] Fix v3 duplicate constructors problem
Date: Mon, 03 Dec 2001 13:52:00 -0000 [thread overview]
Message-ID: <wvlsnasdle4.fsf@prospero.cambridge.redhat.com> (raw)
In-Reply-To: <20011203154836.A28821@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 3 Dec 2001 15:48:36 -0500")
>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
[redirected to gcc list, rather than libstdc++]
> I tracked down the annoying duplication of constructors using G++ 3.0 with
> stabs. The problem is that all the clones of the constructor are emitted,
> so there really are two of them.
Yep.
> The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> instead of DECL_ABSTRACT. That works for eliminating the duplicates and
> creating the names we need, but the mangled name in debug info is the
> "*INTERNAL*" version if we do that. I'd like to emit the name of the
> constructor and the mangled name of the complete object constructor,
> ideally. C++ people, does that sound right? Or feasible?
It's certainly feasible; when we see the abstract version, look ahead for a
clone and use its mangled name.
The thing is, we want the debugger to treat them as the same function, so
that setting a breakpoint on the signature actually sets one on each and
the like. I suppose that ideal will not be affected by your change, both
because (I assume) it doesn't work now and because we use the demangled
names for most purposes anyway.
What does GDB actually use the member function information for? What
impact would this change have, other than the output of ptype?
Jason
next prev parent reply other threads:[~2001-12-03 21:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 12:48 Daniel Jacobowitz
2001-12-03 13:22 ` Daniel Berlin
2001-12-03 13:25 ` Daniel Jacobowitz
2001-12-03 13:28 ` Daniel Berlin
2001-12-03 13:52 ` Jason Merrill [this message]
2001-12-03 14:29 ` Daniel Jacobowitz
2001-12-03 14:58 ` Jason Merrill
2001-12-03 15:25 ` Michael Snyder
2001-12-04 8:25 ` Jason Merrill
2001-12-04 8:53 ` Jim Blandy
2001-12-04 9:43 ` Joe Buck
2001-12-07 15:25 ` Jim Blandy
2001-12-07 15:30 ` Daniel Jacobowitz
2001-12-04 1:09 Michael Elizabeth Chastain
2001-12-04 5:27 ` Jason Merrill
2001-12-04 7:40 ` Daniel Berlin
2001-12-04 8:58 ` Daniel Jacobowitz
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=wvlsnasdle4.fsf@prospero.cambridge.redhat.com \
--to=jason@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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