From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9268 invoked by alias); 29 Apr 2003 20:39:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9209 invoked from network); 29 Apr 2003 20:39:11 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 29 Apr 2003 20:39:11 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3TKd4Q24636; Tue, 29 Apr 2003 13:39:04 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb , Elena Zannoni , Jim Blandy Subject: Re: [rfc] struct dictionary References: <3EA89AB3.6050403@redhat.com> <3EAE95CD.8070207@redhat.com> <3EAEDB2A.2050207@redhat.com> From: David Carlton Date: Tue, 29 Apr 2003 20:39:00 -0000 In-Reply-To: <3EAEDB2A.2050207@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-04/txt/msg00335.txt.bz2 On Tue, 29 Apr 2003 16:06:02 -0400, Andrew Cagney said: >> I kind of get the impression that I'm missing your point somehow >> and that we're talking past each other. I'll post a concrete patch >> soon (Wednesday, maybe? It's done on my laptop, but I don't have >> my laptop with me), and hopefully that will clarify matters. > Sounds like it. I'm think I'm looking a step beyond your changes. Good, because I think/hope so too. > Is the block's symbol search algorithm determined by the language? Sort of yes, sort of no. lookup_block_symbol itself doesn't depend on the language: it has one subtlety that depends, basically, on whether or not the block is associated to a function, but that doesn't have anything to do with the language. But that's just lookup_block_symbol. lookup_symbol itself implements C/C++ name lookup, so if languages are too different from C or C++, they might have to implement their own custom lookup rules. And, unfortunately, my current namespace patch that's awaiting review increases the amount of C++-specific cruft in there. It does it in such a way that the C execution path shouldn't get slowed down, but I'm still not happy with its presence at all: currently, GDB is too C-centric, but changing that to being C++-centric isn't exactly an improvement. (For what it's worth, until my first namespace patch, struct block didn't have a language_specific member at all.) There shouldn't be anything in any of these functions that depends on the language of the symbols themselves. There's some code in various functions to treat Java symbols differently when searching, but that code really shouldn't be there. I have some ideas about representing things like using directives, anonymous namespaces, namespace scope, and for that matter the simple case of looking up a C global variable in terms of dictionaries. I want to get things working first in a way that is, I think, not too hard to understand, but I hope there will be time to reflect on the situation later and change the implementations to move more of the C++-specific code to a more appropriate location. One issue that we'll have to grapple with is that the language-specific rules aren't really localized to a single block. For example, name lookup looks something like this: 1) Look in local variables. 2) Look to see if we're referring to a member of the current class. 3) Look in global and static variables. Now, step #2 isn't relevant to C, and for that matter I would imagine that different object-oriented language might have some subtle differences in the exact semantics of step #2. So it's a good candidate for a language-specific hook: but where should the hook go? We don't want to do this all the time, after all: only if we're executing a member function. And currently that information doesn't really fit into our blocks at all. I can imagine possible solutions. One is to move BLOCK_SUPERBLOCK inside of dictionaries, and then allow dictionaries to implement their own strategies for what do do next (basically, to let them implement lookup_symbol instead of just lookup_block_symbol). Another possibility would be to, when creating the block associated to a method, have its superblock not be the current file's static block but instead be a dummy block that exists only to provide a dictionary to lookup a member of the current class. (Of course, this also raises the problem that members aren't represented by symbols: so what do we do about that?) I'm sure that there are other possibilities as well; I'm not sure which of them is best. And I also don't know exactly what effects this will have on the symbol readers. David Carlton carlton@math.stanford.edu