From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24285 invoked by alias); 23 Oct 2002 23:36:35 -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 24196 invoked from network); 23 Oct 2002 23:36:31 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Oct 2002 23:36:31 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B36373D4A; Wed, 23 Oct 2002 19:36:22 -0400 (EDT) Message-ID: <3DB73276.5000108@redhat.com> Date: Wed, 23 Oct 2002 16:36: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: Andrew Cagney 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00174.txt.bz2 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