From: Michael Elizabeth Chastain <mec@shout.net>
To: gdb-patches@sources.redhat.com, jason@redhat.com
Cc: gcc@gcc.gnu.org
Subject: Re: [RFA/stabs reader] Fix v3 duplicate constructors problem
Date: Tue, 04 Dec 2001 01:09:00 -0000 [thread overview]
Message-ID: <200112040909.DAA30310@duracef.shout.net> (raw)
Jason Merrill writes:
> 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 for one do not want that to happen at all!
There really are two bodies of code in the target program code.
The compiler emits two bodies of code; the linker recognizes two bodies
of code with different names.
Consider this code:
class C1 { public: C1::C1(); };
C1::C1 () { foo(); bar(); bletch(); }
Suppose the user sets a breakpoint in foo(), looks at the stack,
and sees the name C1::C1(). They decide they want to read the machine
language instructions for the constructor, so they type "disass C1::C1".
What do you want gdb to do?
I would like gdb to demangle different names differently. Perhaps:
(gdb) ptype C1
... C1::C1 ...
... C1::C1$base ...
... where the first line is for the in-charge constructor, and the second
line is for the not-in-charge constructor. Then the user can disassemble,
breakpoint, and call whichever function they want (they better know what
they are doing if they call a not-in-charge constructor by hand though).
If they don't know what C1::C1$base is, they can read a document, where
they can learn that each constructor and destructor in the source code is
compiled to multiple object functions in the object code, with different
interfaces and purposes.
As to how this relates onto symbol handling, I don't know. I just know
that I want names that reflect reality in ptype, disassmble, break,
and backtrace.
Michael C
next reply other threads:[~2001-12-04 9:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-04 1:09 Michael Elizabeth Chastain [this message]
2001-12-04 5:27 ` Jason Merrill
2001-12-04 7:40 ` Daniel Berlin
2001-12-04 8:58 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
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
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
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=200112040909.DAA30310@duracef.shout.net \
--to=mec@shout.net \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jason@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