From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5138 invoked by alias); 4 Oct 2002 21:57:35 -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 5111 invoked from network); 4 Oct 2002 21:57:34 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 4 Oct 2002 21:57:34 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g94LvWN12555; Fri, 4 Oct 2002 14:57:32 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: Jim Blandy Subject: current namespace game plan From: David Carlton Date: Fri, 04 Oct 2002 14:57:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00044.txt.bz2 I've been tossing around namespace ideas in my head for a while, and they're starting to converge on a game plan that makes sense to me; I wanted to run it by other people. Feel free to skip the parts of this message starting with "So that's the first step". The initial goal is to have GDB work about as well as it does now, with the addition that lookup of global symbols will be more likely to find symbols in namespaces where appropriate (and where the compiler provides enough debugging information). There are a few ways that you can add namespaces that should be searched during symbol lookup: * By explicit 'using' directives. * By anonymous namespaces. * By looking at what namespace the current function is defined in. * By looking at the arguments of a function that you're trying to call. I won't go into details; current compilers don't give us enough information to recover the first of those, but we should probably be able to have enough information to handle the other three cases. And Daniel Berlin has posted patches to get GCC to generate the debugging information for the first of those. So if I want to do a minimal change to GDB's data structures to allow this, the thing to do seems to be to add a C++-specific field to struct block that says what additional search namespaces should be added to the search list if you're doing name lookup within that block. And then modify the symbol table readers to initialize that field appropriately, and modify the various symbol lookup functions to, when they hit the global environment, try adding all of those namespaces to the beginning of the symbol name that you're searching for. There will also have to be some changes to C++-specific code to do name lookup of functions correctly based on their arguments. This will only modify symbol lookup, not how symbols are stored: A::var will still be stored in some global block just like it is now. So that's the first step; that should require relatively small changes to GDB, and will significantly improve GDB's namespace behavior. After that, though, there will still be some problems that remain; here are some that come to mind: * If a 'using' statement comes in the middle of a block, GDB will interpret as affecting the whole block. I don't think it's worth spending time to get rid of it; it's not that important, and this part of GDB's architecture is pretty centered on treating blocks as undifferentiated wholes. (There are certainly non-namespace related bugs in this area.) * Some C++ constructs won't get handled correctly: aliasing namespaces (e.g. 'namespace B = A;') or importing single variables from other namespaces ('using A::foo;'). I think the architecture from the first step might be able to be modified to handle the latter; maybe not, though, and it certainly won't be able to gracefully handle the former. That won't come until further down the road. * We get the semantics of current lookups wrong. E.g. lookup_symbol_aux does the is_a_field_of_this stuff at the wrong time. I suspect that overloading is a mess, and I suspect that we don't deal with static variables correctly. These problems are more serious, and I want to solve them as part of the second step of this process. So the second step will involve cleaning up current code, both to fix the semantics of variable lookup and to just refactor the design of existing code to clean it up. (E.g. perhaps both lookup_symbol and the code for doing overload resolution could call the same iterator functions to track down symbols.) Hopefully Daniel Jacobowitz can get shanghaied into helping here. Ideally, I'd be able to get rid of the 'symtab' argument to lookup_symbol as well as the global variable 'block_found' in this stage. Once the second step is done, there will still be problems: we still won't handle all C++ constructs correctly (the namespace aliasing and using-directives that I mentioned above), and there will still be too much C++-specific stuff in code that everybody has to look at, which is unfortunate. I hope that, at this stage, I'll be able to modularize the notions of lookup algorithms so that different languages can implement their own weird lookup rules without affecting other languages. And, as a bonus, we can speed up symbol lookup considerably. That's the third step; it's vague enough that I don't want to talk about it now. David Carlton carlton@math.stanford.edu