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.