From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3471 invoked by alias); 18 Feb 2004 00:43:15 -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 3438 invoked from network); 18 Feb 2004 00:43:13 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 18 Feb 2004 00:43:13 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 07D541A448A; Tue, 17 Feb 2004 19:38:56 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16434.46111.793011.404391@localhost.redhat.com> Date: Wed, 18 Feb 2004 00:43:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME In-Reply-To: <20040217192919.GA31445@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> <16434.26365.373673.881423@localhost.redhat.com> <20040217192919.GA31445@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00493.txt.bz2 Daniel Jacobowitz writes: > 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. > Did you identify specific bottlenecks? > Do you have an answer to my question? Without one I don't understand > what Andrew is asking of me. > I don't speak for Andrew. I think he replied anyway. > 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. > I had to pry this info out of you over a few e-mail exchanges. Your first posting didn't explain what you were doing, just that you were testing some new approach. Since the patch seemed to be put together in a hurry (and that's why I asked you to split it) I honestly wanted to know what you were planning to do, especially since you are adding a new macro. So it seemed to me that you were doing exactly that: going ahead with the first stages of a big change but that the change itself hadn't been discussed. > 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. > thank you. What do you mean by separate? Where would you store the demangled name? Have it demangled on demand only?