From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13680 invoked by alias); 1 Apr 2004 15:21: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 13653 invoked from network); 1 Apr 2004 15:21:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Apr 2004 15:21:12 -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 i31FLCjj010394 for ; Thu, 1 Apr 2004 10:21:12 -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 i31FLBj27479; Thu, 1 Apr 2004 10:21:11 -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> <20040401150022.GA30729@nevyn.them.org> From: Jim Blandy Date: Thu, 01 Apr 2004 15:21:00 -0000 In-Reply-To: <20040401150022.GA30729@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/msg00023.txt.bz2 Daniel Jacobowitz writes: > On Thu, Apr 01, 2004 at 09:52:46AM -0500, Jim Blandy wrote: > > > > 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? > > Well, (A) it's inefficient, since there's no pointer from the BFD > section to the GDB section; (B) I don't know whether we produce minsyms > whose sections are unset; (C) I really want to remove the section > pointer from general_symbol_info someday, and this will make that > harder. I've abandoned that project for the moment while I catch up on > other projects, but I'll be back to it :) Yes, (A) was apparent; by asking correctness questions I didn't mean to imply I thought efficiency was a done deal. :) (B) is the real question; if someone knows that we do produce such symbols, I'd love to hear about it. (C) is good to know, too. I have to say, I think our allocation rules are hairy enough already. If there is some better solution on the horizon for lazy demangling's allocation, I am relucantant to put in complex and slow mechanisms, even temporarily. It's a step backwards, justified by work that isn't even scheduled. Paul, how critical is this to the intent of your change? I haven't reviewed it.