From: Daniel Jacobowitz <drow@mvista.com>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb@sources.redhat.com, Benjamin Kosnik <bkoz@redhat.com>,
Daniel Berlin <dan@dberlin.org>
Subject: Re: C++ nested classes, namespaces, structs, and compound statements
Date: Mon, 08 Apr 2002 18:59:00 -0000 [thread overview]
Message-ID: <20020408215921.B14098@nevyn.them.org> (raw)
In-Reply-To: <np1ydpspql.fsf@zwingli.cygnus.com>
On Mon, Apr 08, 2002 at 07:02:58PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > GDB already does a great deal of this by the very simple method of
> > using fully qualified names. It's served us remarkably well, although
> > of course we're hitting its limits now. But let's not be too quick to
> > discard that approach, for the present at least.
>
> Oh dear. I think that's exactly what I'm proposing we replace. As
> Per said:
> In that situation, we can look up things like `B2::A2::x' in a
> straightforward way: look up B2, look up A2 there, and look up x
> there. With a symbol table full of fully qualified names, how do we
> do this?
>
> Can you talk more about why we shouldn't evolve away from placing
> fully qualified names in the symbol table directly, and towards
> representing them more explicitly?
Let me be a little clearer on what I wanted to say there: I agree
completely that your approach is cleaner, more efficient, more
adaptable, more useful, and generally better than what we have now.
But let me put my cynic's cap on for a moment and point out some
problems. I'd love to see us just decide to overcome them all, and I
think it's viable, but we need to make sure we consider them first.
The "incremental change" Problem
Could we write the necessary wrapper functions to simulate lookup of
a fully qualified name and use them everywhere we haven't changed yet?
Probably a non-issue. How much will have to be changed at first to
make this functional? For instance, all the debug readers would be
substantially affected.
The "big change" Problem
There's plenty of places in GDB that assume the current name lookup
behavior. We'd have to do a lot of digging to make sure we did scoped
lookups everywhere that needed them. On the upside, we could use this
as an excuse for some really rocking test coverage improvements.
The "debug info" Problem
DWARF-2 gives us enough information for this. Sun's stabs extensions
(well, recent definitions; it being their format and all) also give us
enough information. HP's stuff probably does, but I don't know if
we've got anyone that knows it well enough to update. For most other
formats, we'd just have to fake it as well as we could and hope for the
best. Look at the debugging output GCC 3.0 / -gstabs+ puts out for
namespaces or even nested classes sometime.
I'm sure I had another in mind, but it slips my mind at the moment.
For debug info, we could probably add a 'unknown_scope_kind' to the
enum name_kind I described in my other message, and change all
periods/colons etc. into those. For free, this hierarchy would let us
associate out-of-line member function definitions directly with the
types, which would make my life in C++-land much nicer!
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-04-09 1:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-05 20:42 Jim Blandy
2002-04-05 22:05 ` Daniel Berlin
2002-04-05 22:34 ` Daniel Jacobowitz
2002-04-05 23:49 ` Daniel Berlin
2002-04-06 7:18 ` Dan Kegel
2002-04-06 9:26 ` Gianni Mariani
2002-04-06 11:57 ` Daniel Berlin
2002-04-08 17:24 ` Jim Blandy
2002-04-08 17:03 ` Jim Blandy
2002-04-08 18:59 ` Daniel Jacobowitz [this message]
2002-04-09 18:35 ` Jim Blandy
2002-04-09 20:56 ` Daniel Jacobowitz
2002-04-12 15:08 ` Jim Blandy
2002-04-12 16:32 ` Daniel Jacobowitz
2002-04-08 17:19 ` Jim Blandy
2002-04-08 18:49 ` Daniel Jacobowitz
2002-04-10 10:31 ` Jim Blandy
2002-04-10 12:08 ` Daniel Jacobowitz
2002-04-12 13:58 ` Jim Blandy
2002-04-12 16:56 ` Daniel Jacobowitz
2002-04-16 12:08 ` Jim Blandy
2002-04-16 14:01 ` Daniel Jacobowitz
2002-04-16 14:52 ` Jim Blandy
2002-04-16 14:58 ` Daniel Jacobowitz
2002-04-06 6:31 ` Andrew Cagney
2002-04-06 7:58 ` Daniel Berlin
2002-04-08 0:59 ` Joel Brobecker
2002-04-08 2:01 ` Doubt in GDB SathisKanna k
2002-04-06 8:49 ` C++ nested classes, namespaces, structs, and compound statements Per Bothner
2002-04-08 16:29 ` Jim Blandy
2002-04-08 16:48 ` Daniel Jacobowitz
2002-04-09 6:55 ` Petr Sorfa
2002-04-10 10:34 ` Jim Blandy
2002-04-10 12:31 ` Daniel Berlin
2002-04-10 12:53 ` Petr Sorfa
2002-04-05 22:02 Michael Elizabeth Chastain
2002-04-05 22:13 ` Daniel Berlin
2002-04-05 22:30 ` Daniel Berlin
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=20020408215921.B14098@nevyn.them.org \
--to=drow@mvista.com \
--cc=bkoz@redhat.com \
--cc=dan@dberlin.org \
--cc=gdb@sources.redhat.com \
--cc=jimb@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