From: Elena Zannoni <ezannoni@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: David Carlton <carlton@math.stanford.edu>,
Elena Zannoni <ezannoni@redhat.com>,
gdb-patches@sources.redhat.com, Jim Blandy <jimb@redhat.com>
Subject: Re: [rfa] annotate blocks with C++ namespace information
Date: Tue, 15 Apr 2003 02:26:00 -0000 [thread overview]
Message-ID: <16027.28339.641147.70506@localhost.redhat.com> (raw)
In-Reply-To: <20030415020820.GB30534@nevyn.them.org>
Daniel Jacobowitz writes:
> On Mon, Apr 14, 2003 at 02:33:03PM -0700, David Carlton wrote:
> > On Mon, 14 Apr 2003 15:27:05 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> > > David Carlton writes:
> >
> > >> Just for reference, here's a slightly updated version of my namespace
> > >> patch, following Daniel's suggestions. The only real change is that
> > >> it adds a new command "maint cplus first_component" and a new file
> > >> gdb.c++/maint.exp to test it.
> >
> > > Ok, I got around to this finally. It is basically ok, except for the
> > > line between what is c++ and what is symbol table stuff. I think that
> > > more stuff can be pushed into cp-support.c. See below...
> >
> > I have mixed feelings about your comments. My first reaction was the
> > 'using_list' stuff more logically belongs in buildsym.c: it's about
> > building a symtab, after all! So if the only reason to move it to
> > cp-support is to shift the maintenance responsibilities (which is
> > sensible enough, no need for you to look at changes that only affect
> > C++ support), then I'd rather fix the maintenance process: make Daniel
> > a symtab maintainer (he's certainly done enough work on symtabs), or
> > at least allow him to approve C++-specific symtab changes.
> >
> > Having said that, I'm tentatively coming around to your point of view.
> > After all, it's easy enough for me to say that everything related to
> > building symtabs should be in buildsym.c, but if lots of different
> > languages develop their own special needs for the symbol table, then
> > buildsym.c will quickly degenerate into a mess of language-specific
> > special cases. So maybe you're right. And, after all, cp-support.c
> > is a lot smaller than buildsym.c, so it will be a while before it gets
> > too bloated.
> >
> > Daniel, what do you think?
>
> I can see it either way - in symtab or in C++. Does it make sense to
> have cp-namespace.c for this, do you think?
I see it more as building language specific structures, and letting
symtabs have a pointer to those. I think the cp-namespace.c idea is a
good compromise.
elena
>
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-04-15 2:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-22 1:47 David Carlton
2003-03-11 17:11 ` Daniel Jacobowitz
2003-03-11 21:14 ` David Carlton
2003-03-11 21:23 ` Daniel Jacobowitz
2003-03-11 22:43 ` David Carlton
2003-03-11 22:59 ` David Carlton
2003-03-11 23:01 ` Daniel Jacobowitz
2003-03-17 22:33 ` David Carlton
2003-04-14 19:22 ` Elena Zannoni
2003-04-14 21:33 ` David Carlton
2003-04-15 2:08 ` Daniel Jacobowitz
2003-04-15 2:26 ` Elena Zannoni [this message]
2003-04-15 3:07 ` David Carlton
2003-04-15 23:12 ` David Carlton
2003-04-16 1:22 ` Elena Zannoni
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=16027.28339.641147.70506@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@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