This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] teach lookup_symbol about namespace scope
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, cagney at redhat dot com, gdb-patches at sources dot redhat dot com, Jim Blandy <jimb at redhat dot com>, Adam Fedor <fedor at doc dot com>
- Date: 16 May 2003 10:26:11 -0700
- Subject: Re: [rfa] teach lookup_symbol about namespace scope
- References: <m3n0igvg9w.fsf@papaya.bactrian.org><20030424143356.GB7249@nevyn.them.org><ro1ist3x57i.fsf@jackfruit.Stanford.EDU><16068.64366.311139.220476@localhost.redhat.com>
On Fri, 16 May 2003 10:53:34 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> OK, here it goes. I have been ruminating on this patch a long time,
> and I have really mixed feelings about it, no that's not accurate, I
> am completely torn about it.
I'm not surprised to hear that, because I basically share your
qualms.
> On the other hand, the generic flow of control of the symbol search
> gets pulled into c++ territory.
Right. So what do we do about that? Some possibilities:
1) Have a separate lookup-symbol function for each language, and make
sure it gets called wherever is appropriate.
2) Put language-specific hooks in the generic lookup_symbol function.
3) Have the knowledge about what to do actually embedded in the blocks
themselves.
I don't think option 1 is all that great an idea: e.g. C and C++ share
a parser (and might eventually share it with Objective C as well), so
you don't know which lookup function to call, or in decode_variable
(within decode_line_1), you don't really know what the ambient
language is, so you really want a single function that works for all
languages.
Option 3 might well be a good idea in the long term, and probably my
dictionary patch will begin to set up the framework necessary for
that, but it's far too big a leap for me to want to consider that now:
I just want to get C++ working better.
So that leaves us with option 2. And, actually, I think there's a
natural place to put a hook:
* Allow languages complete control as to what happens after the local
variables are looked up.
Local variable lookup is, I hope, fairly uniform across languages.
But the 'is_a_field_of_this' check isn't relevant to C. The new
namespace stuff isn't relevant to C. And all of that happens after
local variables are looked up, either before or instead of
global/static symbol lookup. So that seems to me to be the right
place to allow languages to seize control; if we need more hooks
later, we can add them, but that will give us some place to start, and
will allow me to move my namespace lookup algorithm to cp-support.c or
cp-namespace.c. I assume this would work for whatever needs
Objective-C has; I'll add Adam to the Cc: list in case he wants to
chime in. (We should really add him to the MAINTAINERS list as
Objective-C maintainer one of these days.)
To get this to work, we'll obviously need to provide a way to locate
the language associated to a given block. My first instinct was to
add a 'language' member to each block, but poking around, the symtab
already has that information: how about just adding a 'symtab' member
to each block? (Or even just to global blocks, if that is any easier
to write: we can bury the details of its access in a function
'block_symtab'.) That would help make sure that the information is
consistent, and would let us get rid of the ALL_SYMTABS bit in
lookup_symbol_aux_block.
If this sounds good, I'll get to work on it; it should be easy enough
to do, I think. I have a pretty good idea of what functions symtab.c
will want to export to make life easier for other languages.
> Anyway, here is the symtab.c portion of the patch updated to reflect
> the namespace-->domain changes.
Thanks.
> (about the test changes: do you use namespace1.cc at all? I don't see
> you hooking that up to anything).
Oh, whoops, sorry about that. Good thing Daniel was asking me to
include tests for symbols in namespace1.cc that are actually supposed
to find a variable instead of not do so...
David Carlton
carlton@math.stanford.edu