This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: current namespace game plan
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