From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20233 invoked by alias); 30 Mar 2004 09:37:19 -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 20184 invoked from network); 30 Mar 2004 09:37:10 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 30 Mar 2004 09:37:10 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 90955F2A45 for ; Tue, 30 Mar 2004 04:37:09 -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 04416-01-2 for ; Tue, 30 Mar 2004 04:37:09 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 448BCF28C5; Tue, 30 Mar 2004 04:37:09 -0500 (EST) From: Paul Hilfinger To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" Message-Id: <20040330093709.448BCF28C5@nile.gnat.com> Date: Tue, 30 Mar 2004 09:37:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-03/txt/msg00743.txt.bz2 Ping. I have not yet received a reply after my last message on this patch, posted Wed, 3 Mar 2004 14:15:50 -0500 (EST). For reference, I have appended the initial discussion (minus patch), plus my responses to David Carlton and Daniel Jacobwitz. David and Daniel suggested some minor changes, which you may consider made, but I haven't received any definitive word. Paul Hilfinger ------------------------------------------------------------ Original discussion of 3 March. The following patch does nothing except to prepare the way for some later Ada modifications by providing a few "hooks". I've discussed this modification earlier on this newsgroup. At the moment, I've given the definitions placeholder definitions that simply result in the current semantics. I propose to change them when Ada support is turned on. The idea is to define "search name" as "the name that a language module uses when searching for this symbol". As discussed earlier, the search name would be normally be the natural name, but in the case of Ada, would just be the linkage name. The modification to the signature of symbol_natural_name is to allow the option of delayed (lazy) evaluation of the demangled name, which is actually the point of introducing search names. Paul Hilfinger 2004-03-03 Paul N. Hilfinger * symtab.h (symbol_natural_name): Remove const qualification from argument. (SYMBOL_SEARCH_NAME): New definition. (SYMBOL_MATCHES_SEARCH_NAME): New definition. (SYMBOL_DEMANGLED_SEARCH_NAME): New definition. * dictionary.c (iter_name_first_hashed): Match on SYMBOL_SEARCH_NAME. (iter_name_next_hashed): Ditto. (iter_name_next_linear): Ditto. (insert_symbol_hashed): Hash on SYMBOL_SEARCH_NAME. * symtab.c (symbol_natural_name): Remove const qualification from argument to allow lazy evaluation of demangled name. (lookup_partial_symbol): Assume symbols ordered by search name, using SYMBOL_SEARCH_NAME and SYMBOL_MATCHES_SEARCH_NAME. * symfile.c (compare_psymbols): Order by SYMBOL_SEARCH_NAME. * minsyms.c (build_minimal_symbol_hash_tables): Use SYMBOL_DEMANGLED_SEARCH_NAME to test for adding to demangled hash table. ------------------------------------------------------------ Reply to David Carlton of Thu, 4 Mar 2004 03:45:22 -0500 (EST) > Personally, I would leave the signature as is and cast away the > constness when you eventually add this lazy demangling. My > justification is that the operation is logically a const operation; > you're planning to generate some information on the fly, but it > wouldn't actually change the state of the object. Sounds fine to me. I suppose that would be as close to the "mutable" idiom as one can come in C. Paul Hilfinger Hilfinger@gnat.com ------------------------------------------------------------ Reply to Daniel Jacobowitz of Fri, 5 Mar 2004 05:39:25 -0500 (EST) 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.