current namespace game plan

[David Carlton <carlton at math dot stanford dot edu>]

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