From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17935 invoked by alias); 31 Mar 2004 22:12:49 -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 17925 invoked from network); 31 Mar 2004 22:12:47 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 31 Mar 2004 22:12:47 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B8nx3-0001qH-KD; Wed, 31 Mar 2004 17:12:49 -0500 Date: Wed, 31 Mar 2004 22:12:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" Message-ID: <20040331221249.GA6811@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , gdb-patches@sources.redhat.com References: <20040303191550.7307DF2DB8@nile.gnat.com> <20040305035955.GH5320@nevyn.them.org> <20040305103925.A4815F2EE4@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040305103925.A4815F2EE4@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00772.txt.bz2 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. > > You define SYMBOL_DEMANGLED_SEARCH_NAME. What's it really good for, > > and how does it do any good? You only use it for the minimal symbol > > hash tables; the fundamental problem with minimal symbols is that we > > don't know their language, so I don't know how you can reliably make a > > language-specific decision like this one. What you did not explain is how this is supposed to be different from SYMBOL_SEARCH_NAME. > The relevant code now reads > > if (SYMBOL_DEMANGLED_NAME (msym) != NULL) > add_minsym_to_demangled_hash_table (msym, > objfile->msymbol_demangled_hash); > > Ada does demangle; SYMBOL_DEMANGLED_NAME does have to return a > demangled name, if there is one. Therefore the test here will > precipitate computing and caching the demangled name prematurely (once > symbol_demangled_name is extended to include the Ada case). This code > also adds the demangled name to the hash table. But we never look for > demangled names, so that is a waste. > > As to your question about how this can work: Ada doesn't really change > your question. I could just as well ask "How can > SYMBOL_DEMANGLED_NAME work on minimal symbols, given that it doesn't > know what language to use for demangling?" The answer is that if it > quacks like a duck ... excuse me, I mean if ObjC demangling works, > assume you have an ObjC symbol, if C++ demangling works, then assume > it is a C++ symbol, etc., and hope that the demangling schemes don't > collide. That's what the code says now. You'll have to argue the > sensibility of this strategy with others. The existing ada_demangle never fails. How does that interact with what you said above? Hopefully not by tagging all minsyms as Ada! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer