Re: current namespace game plan

[Jim Blandy <jimb at red-bean dot com>]

For my own sake, at least, it would be nice to have specific examples
of code and commands that GDB gets wrong at present.  If they're as
obvious as they sound, I may try to whip up some examples myself and
turn them into test cases.

David Carlton <carlton@math.stanford.edu> writes:

> 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