From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23410 invoked by alias); 24 Oct 2002 01:22:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23403 invoked from network); 24 Oct 2002 01:22:45 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 24 Oct 2002 01:22:45 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7B4B23D4A; Wed, 23 Oct 2002 21:22:43 -0400 (EDT) Message-ID: <3DB74B63.3080504@redhat.com> Date: Wed, 23 Oct 2002 18:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: David Carlton , Elena Zannoni , Jim Blandy , gdb Subject: Re: current namespace game plan References: <15789.43864.432576.737958@localhost.redhat.com> <3DB41A90.4070403@redhat.com> <3DB73276.5000108@redhat.com> <20021023234729.GA5916@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00176.txt.bz2 > 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