Re: current namespace game plan

[Andrew Cagney <ac131313@redhat.com>]

> On Wed, Oct 23, 2002 at 07:36:22PM -0400, Andrew Cagney wrote:
> 
>> - 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?
> 
> 
> I believe several people have said that Apple finished and uses this,
> and that it is useful to them.  Which puts things in a different light.

GDB's experience with [large] merges is that they always degenerate into 
rewrites. I, unfortunatly, can't think of a reason to expect this 
feature's merge to be any different.  I also think that people working 
on cleaning up GDB's symtab code already have enough to contend with, 
without, that is, also having to worry about preserving the existing 
memmap code so that some hopothetical merge will be made easier. 
Instead I think the objective should be to focus solely on getting the 
basic code into shape, and then (and only then) consider new features 
such as this which was prototyped by Apple.

On an unrelated matter, I should respond to your last HP follow-fork 
post :-^

>> 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.
> 
> 
> But I don't see that most of these structural improvements are
> necessary for the work David is doing...

As with the frame code, I've taken the more long term approach of 
cleaning up the existing code and tightening the interfaces, so that the 
CFI stuff can slip in (instead of just grafting the CFI code on top of 
the existing mechanisms as was done with x86-64).

An old old house, like GDB, needs constant maintanenace as without it, 
it will quickly fall into disrepair and crumble.

Andrew