Re: [rfa] teach lookup_symbol about namespace scope

Elena Zannoni
2003-05-16T19:49:53Z

David Carlton writes:
> 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.

pheeew! :-)

>
> > 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.
>

If by option 1 you mean the main lookup_symbol, I agree with the
above. It is called in places where you are not sure what to do.

> 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.

Option 3 is the long term goal, I think Adndrew agrees with this and
has ideas about integrating language knowedge with frames. For this we
need to better understand the ada code as well, and I haven't looked
at it too closely. Ideally I would like to have namespace support in
gdb 6, so we have a tradeoff to make.

>
> 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.)
>

This is what I was trying to say. If we could branch off the main
search algorithm to do language specific actions. I was thinking that
the current algorithm could be left in place, and yours could be used
in case of c++ being detected.

for the record the algorithm goes roughly like this (correct me if not):

0. search symbol in local block
1. search symbol in static block of the current file
2. search symbol in all symtabs of the global blocks for the program
3. search symbol in all psymtabs of the global blocks for the program
4. search symbol in all symtabs of the static blocks for the program
5. search symbol in all psymtabs of the static blocks for the program

You have moved 1, 2, and 3 within the new namespace lookup algorithm,
which becomes a no-op for the non-c++ case. I was wondering if we
could leave 1 through 5 in place, and have a c++ version for 1, 2, 3.
Well, to be honest I was thinking that we could do

0.
<cplus stuff> or <ada stuff> or <objc stuff> or....
1.
2.
3.
4.
5.

instead of

0.
|_______________
|\ \ \
| \ \ \
1. 1c++ 1ada 1objc .....fortran, pascal,....
2. 2c++ 2ada 2objc
3. 3c++ 3ada 3objc
| / / /
|/_______/______/
4.
5.

But I see now that with each scope algorithm being basically language
specific, we may not be able to do what I first intended.

(even 1.2.3. are actually C specific, so we will probably end up w/o a default
search algorithm, don't know)

Hmm, thinking out loud. What about 'set language blah'? Should this
honor that?

> 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.

hmm, I am wondering, we have language info in the symtab, and in the
symbols already, do we need it to add it somewhere else too? I think
we could access it like you say. However I am bit concerned that we
would add a lot of loops through the blocks.

>
> 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.

I think it's an ok plan. I think some Ada person should chime in as
well to see if we can resolve the duplication of code in ada-lang.c,
or at least understand what they need out of the symbol table.

elena

>
> > 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