From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25072 invoked by alias); 16 May 2003 17:26:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25043 invoked from network); 16 May 2003 17:26:25 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 16 May 2003 17:26:25 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h4GHQCo12316; Fri, 16 May 2003 10:26:12 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Elena Zannoni Cc: Daniel Jacobowitz , cagney@redhat.com, gdb-patches@sources.redhat.com, Jim Blandy , Adam Fedor Subject: Re: [rfa] teach lookup_symbol about namespace scope References: <20030424143356.GB7249@nevyn.them.org> <16068.64366.311139.220476@localhost.redhat.com> From: David Carlton Date: Fri, 16 May 2003 17:26:00 -0000 In-Reply-To: <16068.64366.311139.220476@localhost.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00285.txt.bz2 On Fri, 16 May 2003 10:53:34 -0400, Elena Zannoni 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