From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 598 invoked by alias); 19 Dec 2002 16:46:27 -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 559 invoked from network); 19 Dec 2002 16:46:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 19 Dec 2002 16:46:24 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gBJGJrg23976 for ; Thu, 19 Dec 2002 11:19:53 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gBJGkB219466 for ; Thu, 19 Dec 2002 11:46:11 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gBJGk9L09336; Thu, 19 Dec 2002 11:46:09 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id E799FFF79; Thu, 19 Dec 2002 11:50:37 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15873.63708.366837.407436@localhost.redhat.com> Date: Thu, 19 Dec 2002 08:54:00 -0000 To: David Carlton Cc: Elena Zannoni , gdb-patches@sources.redhat.com, Jim Blandy Subject: Re: [rfa] delete 'force_return' from lookup_symbol_aux_minsyms In-Reply-To: References: <15861.1750.232869.77936@localhost.redhat.com> X-SW-Source: 2002-12/txt/msg00550.txt.bz2 David Carlton writes: > On Mon, 9 Dec 2002 16:10:46 -0500, Elena Zannoni said: > > > I am tempted to accept it, but could you first look at the > > archeological diggings below? > > Interesting. How did you track that down? I couldn't get CVS to go > back that far when I just tried it. > > > I see that this bit: > > > + else if (MSYMBOL_TYPE (msymbol) != mst_text > > + && MSYMBOL_TYPE (msymbol) != mst_file_text > > + && !STREQ (name, SYMBOL_NAME (msymbol))) > > + { > > + /* This is a mangled variable, look it up by its > > + mangled name. */ > > + return lookup_symbol (SYMBOL_NAME (msymbol), block, > > + namespace, is_a_field_of_this, symtab); > > + } > > + /* There are no debug symbols for this file, or we are looking > > + for an unmangled variable. > > + Try to find a matching static symbol below. */ > > > and this bit: > > > @@ -2629,13 +2684,20 @@ list_symbols (regexp, class, bpt, from_t > > } > > } > > > - /* Here, we search through the minimal symbol tables for functions that > > - match, and call find_pc_symtab on them to force their symbols to > > - be read. The symbol will then be found during the scan of symtabs > > - below. If find_pc_symtab fails, set found_misc so that we will > > - rescan to print any matching symbols without debug info. */ > > + /* Here, we search through the minimal symbol tables for functions > > + and variables that match, and force their symbols to be read. > > + This is in particular necessary for demangled variable names, > > + which are no longer put into the partial symbol tables. > > + The symbol will then be found during the scan of symtabs below. > > + > > + For functions, find_pc_symtab should succeed if we have debug info > > + for the function, for variables we have to call lookup_symbol > > + to determine if the variable has debug info. > > + If the lookup fails, set found_misc so that we will rescan to print > > + any matching symbols without debug info. > > + */ > > > - if (class == 1) > > + if (class == 0 || class == 1) > > { > > ALL_MSYMBOLS (objfile, msymbol) > > { > > @@ -2648,7 +2710,12 @@ list_symbols (regexp, class, bpt, from_t > > { > > if (0 == find_pc_symtab (SYMBOL_VALUE_ADDRESS (msymbol))) > > { > > - found_misc = 1; > > + if (class == 1 > > + || lookup_symbol (SYMBOL_NAME (msymbol), > > + (struct block *) NULL, > > + VAR_NAMESPACE, > > + 0, (struct symtab **) NULL) == NULL) > > + found_misc = 1; > > } > > } > > } > > > were added together in 94. the changelog was: > > > date: 1994/10/08 11:54:20; author: schauer; state: Exp; lines: +87 -20 > > Speed up GDB startup time by not demangling partial symbols. > > * symfile.h (ADD_PSYMBOL_VT_TO_LIST), > > symfile.c (add_psymbol_to_list, add_psymbol_addr_to_list): > > No longer demangle partial symbols. > > * symtab.c (lookup_symbol, list_symbols): Handle mangled > > variables, e.g. C++ static members, via the minimal symbols. > > Hmm. What's 'class'? Does that refer to a variable/function > distinction, or a mangled/demangled distinction? Class was a parameter for the function list_symbols which now is called search_symbols, it has been renamed to 'kind' and cleaned up: If CLASS is zero, list all symbols except functions, type names, and constants (enums). If CLASS is 1, list only functions. If CLASS is 2, list only type names. If CLASS is 3, list only method names. > 'found_misc' also seems to have gone away; Actually it is still there, the code I posted is for list/search_symbols. > maybe that was a hint that callers should > follow up a failed call to lookup_symbol by one to > lookup_minimal_symbol, whereas we now always expect callers to do so > if appropriate, even without the hint. At any rate, I'm particularly > interested by this part of the comment: I forgot to post the bit of code that used found_misc: This is the end of that function, and it is still pretty much the same today. if (found_misc || class != 1) { found_in_file = 0; ALL_MSYMBOLS (objfile, msymbol) { if (MSYMBOL_TYPE (msymbol) == ourtype || MSYMBOL_TYPE (msymbol) == ourtype2 || MSYMBOL_TYPE (msymbol) == ourtype3 || MSYMBOL_TYPE (msymbol) == ourtype4) { if (regexp == NULL || SYMBOL_MATCHES_REGEXP (msymbol)) { /* Functions: Look up by address. */ if (class != 1 || (0 == find_pc_symtab (SYMBOL_VALUE_ADDRESS (msymbol)))) { /* Variables/Absolutes: Look up by name */ if (lookup_symbol (SYMBOL_NAME (msymbol), (struct block *) NULL, VAR_NAMESPACE, 0, (struct symtab **) NULL) == NULL) { if (!found_in_file) { printf_filtered ("\nNon-debugging symbols:\n"); found_in_file = 1; } printf_filtered (" %08lx %s\n", (unsigned long) SYMBOL_VALUE_ADDRESS (msymbol), SYMBOL_SOURCE_NAME (msymbol)); }}}}} > > > + For functions, find_pc_symtab should succeed if we have debug info > > + for the function, for variables we have to call lookup_symbol > > + to determine if the variable has debug info. > > + If the lookup fails, set found_misc so that we will rescan to print > > + any matching symbols without debug info. > > So, at some point, this code had explicit assumptions about when there > should be a symbol corresponding to a minimal symbol, and set > found_misc appropriately. But then, at some point, 'found_misc' went > away; it left, as a legacy, a somewhat strange flow of control that > wasn't at all explicit until I had to introduce 'force_return' to > mimic it. Found_misc is set if lookup_symbol returns null, which then leads to looking through the minsyms. The assumption is that found_misc is set if there is no symbol/debuginfo for a name. With your force_return elimination, is this still the case? I see that it is for the HPPA case, but for the other. You wouldn't return NULL, right there, but would continue searching. Would this matter? I am not sure. Probably you would end up returning NULL anyway later? > > Also, the line > > > + The symbol will then be found during the scan of symtabs below. > > makes me wonder if, at this time, the minimal symbol search happened > before the symtab search; I'm not sure how relevant that is. > > At any rate, this was certainly interesting in terms of giving an idea > as to how the current flow of control might have arisen. I still > think my patch is okay, though. > See above for why I am not truely convinced yet. Does it matter that we keep going with the search instead of stopping? Elena > David Carlton > carlton@math.stanford.edu