Re: current namespace game plan

[Andrew Cagney <ac131313@redhat.com>]

David, humor me .... :-)

You've now figured out that GDB's symbol table and C++ are big nasty 
beasties that need to be tamed.  Unfortunatly they are so big, and so 
nasty that the direct approach (attack, attack) just leads to a near 
death experience - I see you're now somewhat recovered :-)

Anyway, as with a wild animal, can I suggest trying a different approach 
- confine it so that it is no longer able to lash out in all directions. 
  I see that you've even started doing this.

Anyway, to this end I've several idea's:

- Tighten the symtab - core-gdb interface
Here, the objective is to confine the symbol table readers to a very 
small arena so that you know exactly how GDB uses them.  Since GDB 
accesses things though a very tight interface, the symtab code gets 
closer to plug-and-play - drop in a new reader and test it.

- Push the partial symtab code into the stabs reader.
That way, all the partial symtab bufuddlement isn't in core GDB and you 
, and no one else, has to content with it.  Did I mention ``tighten the 
symtab - core-gdb interface''?

- eliminate all that symbol table memory mapping stuff
(Just remembered that this, last time, went into limbo) I really think, 
if symbol table reading is a problem, then better/cleaner solutions can 
be found - thinking about it, changing an already long sequence:
	.c >gcc> .s >as> .o >ld> .out >gdb
into an even longer:
	.c >gcc> .s >as> .o >ld> .out >gdb> .mmap >gdb
is like putting ``good money in after bad''.  At present we're clinging 
to it because it ``might be useful'' - just like so many of those 
unfinished ``#if 0'' blocks ``might be useful'' ....   Time to wield the 
axe?

None of these are directly name-space related.  However, I think that 
they help clear the deck so that you've a better foundation on which to 
build namespaces.

Andrew