From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29755 invoked by alias); 5 Mar 2004 10:39:30 -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 29746 invoked from network); 5 Mar 2004 10:39:26 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 5 Mar 2004 10:39:26 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id EAB43F2E41; Fri, 5 Mar 2004 05:39:25 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25932-01-4; Fri, 5 Mar 2004 05:39:25 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id A4815F2EE4; Fri, 5 Mar 2004 05:39:25 -0500 (EST) From: Paul Hilfinger To: drow@false.org Cc: gdb-patches@sources.redhat.com In-reply-to: <20040305035955.GH5320@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 4 Mar 2004 22:59:55 -0500) Subject: Re: [RFA] Introduce notion of "search name" References: <20040303191550.7307DF2DB8@nile.gnat.com> <20040305035955.GH5320@nevyn.them.org> Message-ID: <20040305103925.A4815F2EE4@nile.gnat.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-03/txt/msg00100.txt.bz2 Message-ID: <20040319000900.GLk6FcdoPSFiwNmUIQ8Oi6AXHV359-GCuAAftHhTCEo@z> 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. > 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. 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. > SYMBOL_DEMANGLED_SEARCH_NAME also codifies more than necessary of the > difference between the other SYMBOL_*_NAME macros and > SYMBOL_SEARCH_NAME. Something that I think may be useful is to use > just the basename for the search name and then have language-specific > code to cherry-pick the resulting matches afterwards; one big advantage > of this is that it lets me sidestep the Java vs. C++ demangling issues. > I suspect it is possible (for all supported languages) to unambiguously > and efficiently identify the basename. I need to look at some of the > other in-use manglings to follow up on that idea though, particularly > g++ v2 and ObjC. Yes, I know: you discussed that before and I eagerly await these changes. For the nonce, I still think I've found a reasonably small hook that accomplishes our purposes. > Oh, and two spaces after a full stop in comments. Oh, woe: of all your comments, this will be the most difficult to accommodate. You see, ACT is full of these confounded Europeans who insist on single spaces after periods and yell whenever I do things properly instead. No doubt they will relent when they hear how this practice will slow up these patches. :->). Paul Hilfinger Ada Core Technologies, Inc.