From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17009 invoked by alias); 1 Apr 2004 14:53:56 -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 16891 invoked from network); 1 Apr 2004 14:53:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Apr 2004 14:53:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31Erpjj031554 for ; Thu, 1 Apr 2004 09:53:51 -0500 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31Ernj17622; Thu, 1 Apr 2004 09:53:49 -0500 To: Daniel Jacobowitz Cc: Paul Hilfinger , gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" References: <20040303191550.7307DF2DB8@nile.gnat.com> <20040305035955.GH5320@nevyn.them.org> <20040305103925.A4815F2EE4@nile.gnat.com> <20040331221249.GA6811@nevyn.them.org> From: Jim Blandy Date: Thu, 01 Apr 2004 14:53:00 -0000 In-Reply-To: <20040331221249.GA6811@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00017.txt.bz2 Daniel Jacobowitz writes: > On Fri, Mar 05, 2004 at 05:39:25AM -0500, Paul Hilfinger wrote: > > Daniel, > > > > > It doesn't address on of the thornier problems I hit when doing the > > > same thing, namely that of allocation. OK, someone uses > > > SYMBOL_DEMANGLED_NAME, we lazily allocate a demangled name - where? The > > > objfile is not available. I think there may be no option but to > > > pass the objfile to SYMBOL_DEMANGLED_NAME. What did you do for Ada? > > > > You're right, I did not address this in the patch proper. I had > > prepared a patch in which I used that extra byte in struct symtab to > > tag the union and allow an objfile member. However, I was aware from > > correspondence with you that you were working in this area, and that > > some of what you proposed to do might eventually allow us to re-do Ada > > symbol lookup. So I decided not to modify the symtab struct for the > > moment, and instead submit a patch that would change as little as > > possible. I figured it would be better not to do anything just now > > that might interfere with on-going work on the symbol table. > > > > So as an interim measure, I use your suggestion of 21 Jan and first > > try to find an objfile via the BFD section. When that doesn't work, I > > simply use a global hashtable to hold the demangled strings. Yes, > > that is a memory leak, but on consideration, I realized that it's only > > REALLY a memory leak if (a) I routinely change the entire set of > > demangled names numerous times during a single GDB session, or (b) > > demangle entirely different, large sets of names each time I reload > > the symbol tables. Yeah, I know, it's not pretty, but again I am hoping > > it will ensure that demangled names behave until the next interation of > > symtab modifications allow an entirely different strategy. > > I'm not sure what others will think of this interim measure. I don't > like it much, though. Under what circumstances does finding an objfile by the minsym's BFD section not work? That minsym must have come from somewhere. Do we produce minsyms whose sections are unset, for some reason?