Re: [rfa] teach lookup_symbol about namespace scope

David Carlton
2003-05-16T20:51:14Z

On Fri, 16 May 2003 15:55:10 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> Some possibilities:

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

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

I'd like to have my branch merged in by GDB 6, but I'm not sure we're
going to be able to finish it. Either way, though, I think that
option 3 should be looked at as a long-term plan that shouldn't stand
in the way of more immediate goals. It seems to me that option 2
would be a natural first step along the journey to option 3: it will
let us get some experience with what sorts of functionality needs to
depend on the current language (or possibly on other data), so that
our eventual design will be nice and clean.

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

There's another step between 0 and 1, where we do the 'field_of_this'
check.

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

Right. I mean, I could write a C++-specific function that searches
all of the namespaces in scope other than the global namespace, in
which case it could fit right before step 1, but it wouldn't be
natural to do so. And steps 1,2,3 are fairly intertwined. For
example, steps 2 and 3 really should be thought of as a single step
"look up a global variable", where the symtab/psymtab issue is an
internal matter for the data structures to deal with. And, in C++,
you can't separate out step 1 from steps 2/3: you have to do them all
for each namespace in scope, so you can't provide a hook for step 1
and another hook for steps 2/3.

So that's why I want to replace steps 1-3 as a whole on a per-language
basis: the breakdown of the algorithm in those steps depends on the
language involved (as well as on the particular data structures being
used).

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

I figure that that we can let the various fallback languages (unknown,
minimal, asm, whatever they're called) default to the C lookup
mechanism.

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

Ah. Right. I hadn't looked at language.h too much when I sent my
last message, but now I see that GDB has a notion of the current
language. So I guess we should use that instead of trying to get
information from the current block somehow?

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

Ada is weird, likes to do things its own way (it apparently handles
(de)mangled names in a completely different way from C++), and doesn't
even compile right now. If some Ada person wants to speak up and talk
about what Ada needs for language lookup, that would be great, but
otherwise I'm not going to worry about it.

David Carlton
carlton@math.stanford.edu