From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9564 invoked by alias); 17 Feb 2004 19:14:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9543 invoked from network); 17 Feb 2004 19:14:05 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 17 Feb 2004 19:14:05 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 9FA2C1A448A; Tue, 17 Feb 2004 14:09:49 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16434.26365.373673.881423@localhost.redhat.com> Date: Tue, 17 Feb 2004 19:14:00 -0000 To: Daniel Jacobowitz Cc: Andrew Cagney , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME In-Reply-To: <20040217160126.GA29934@nevyn.them.org> References: <20040216212406.GC17141@nevyn.them.org> <16433.15049.172030.577544@localhost.redhat.com> <20040216225743.GA1714@nevyn.them.org> <403239F3.70003@gnu.org> <20040217160126.GA29934@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00476.txt.bz2 Daniel Jacobowitz writes: > Because the cleaner interface is not my goal - it's a side goal to my > actual aims, which are improved GDB startup time and memory usage. >From your previous postings I understand is that your cplusplus stuff has a noticeable impact on performance and memory usage and you are trying to shave gdb's time and size wherever there is a chance. From Paul's postings instead I get the impression that he needs to revise the current interface. You are saying that you are not willing to take a step back and look at things from a broader perspective. I sincerely hope I misunderstood your statement. The symbol table is already a mess, with multiple redundant interfaces. At the moment there isn't a clear picture of what various bits of gdb need from the symbol table. How do we know the direction we are going is improving things generally across the board? How can we know that, if this is not the case, the impact is not too heavy on other parts and we can live with the tradeoff? I am not saying that we have to know everything in minutious details before we can touch the code (that's very likely totally unfeasible), but at least, have an understanding of the big picture and the consequences.