From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17709 invoked by alias); 17 Feb 2004 19:29:22 -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 17699 invoked from network); 17 Feb 2004 19:29:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Feb 2004 19:29:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AtAuG-0008G4-0q; Tue, 17 Feb 2004 14:29:20 -0500 Date: Tue, 17 Feb 2004 19:29:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME Message-ID: <20040217192919.GA31445@nevyn.them.org> Mail-Followup-To: Elena Zannoni , Andrew Cagney , gdb-patches@sources.redhat.com 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> <16434.26365.373673.881423@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16434.26365.373673.881423@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00478.txt.bz2 On Tue, Feb 17, 2004 at 02:09:49PM -0500, Elena Zannoni wrote: > 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. This has, in fact, nothing to do with the C++ stuff. This has to do with the fact that when I start GDB on a 200MHz board with debug info in glibc, it takes more than thirty seconds to load partial symbol tables. That's so slow as to be unusable. It makes the entire testsuite timeout, for one thing. > 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. You did. Let me paste that quote with a little more context, OK? > Er, why not start by defining a relevant interface and then work > inwards? That way potential clients, such as paulh, can determine if it > is sufficient for their needs. The first implementation doesn't even > need to be fast, just correct. Once we've hard data on the interfaces > run-time behavioral characteristics we can consider symtab internal > changes. 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. An implementation which is not fast is a step backwards. I don't understand how you can propose to measure "hard data" on "run-time behavioral characteristics" without implementing the symtab internal changes - what am I missing? Do you have an answer to my question? Without one I don't understand what Andrew is asking of me. As for the interface, I don't think that the cleanup patches I've posted so far have any substantial effect on the interface. I was not planning to post that existing grossness, my weekend hack, as a proposal - it was an answer to "can you elaborate". Before submitting patches to implement it I would, I would hope, have asked for comments on the interface. But if I can't make the interface go faster, then there's no point in proposing the interface. That is a work in progress. You want a high level big picture? I would like to separate the concepts of full demangled name for language-specific use and minimalist demangled data (basename, non-DMGL_PARAMS, whatever else) needed for lookups in the symbol table. This lets us reduce the storage used by the symbol table, the data we have to generate at startup, and the data we have to wade through when lookup things up in the tables. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer