From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21919 invoked by alias); 24 Feb 2003 18:52:54 -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 21912 invoked from network); 24 Feb 2003 18:52:53 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 24 Feb 2003 18:52:53 -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 h1OIqre23357 for ; Mon, 24 Feb 2003 13:52: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 h1OIqrq28982 for ; Mon, 24 Feb 2003 13:52:53 -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 h1OIqpI27011; Mon, 24 Feb 2003 13:52:51 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id BF8F7FF79; Mon, 24 Feb 2003 13:56:55 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15962.27382.659097.408682@localhost.redhat.com> Date: Mon, 24 Feb 2003 18:52:00 -0000 To: David Carlton Cc: Elena Zannoni , Daniel Jacobowitz , gdb-patches@sources.redhat.com, Jim Blandy Subject: Re: [rfa] delete lookup_symbol_aux_minsyms In-Reply-To: References: <20030222205011.GA25494@nevyn.them.org> <15962.25283.781474.281523@localhost.redhat.com> X-SW-Source: 2003-02/txt/msg00596.txt.bz2 David Carlton writes: > On Mon, 24 Feb 2003 13:21:55 -0500, Elena Zannoni said: > > > Actually, I did some gcov on that function last night, running make check, > > here is what I got. > > > About deleting the function. I think I would prefer if we delete the > > 'else' part first. Then comment out the function. > > > But I am still not convinced that we should delete it yet. > > I'm not an expert on 'gcov': does the data you presented mean that, in > some situation where lookup_symbol_aux_minsyms was called 1442 times, > the else block was called 2 times? So you're worried about those 2 > times, that they produced correct information that wouldn't have been > reached if we deleted the 'else' clause? > Yes, each number is the number of times that the line is executed. I am not particularly worried about the 'else' clause. I agree that it's dumb. I think it's ok to delete that. The numbers were more like 'food for thoughts'. elena > If so, here's the situation with the 'else' clause. That clause calls > lookup_symbol_aux with a mangled name as the 'name' argument. But the > 'name' argument to lookup_symbol_aux should never be mangled: calls to > lookup_symbol_aux always ultimately boil down to a call to > lookup_block_symbol. And lookup_block_symbol needs a demangled name > as its 'name' argument, not a mangled name: blocks are hashed by their > demangled names, so passing in a mangled name is likely to result in > searching in the wrong bucket. There might be times when > lookup_block_symbol returns the correct value when you pass in a > mangled name as the 'name' argument, but, if so, that's purely > accidental; and, in those situations, the same symbol would have been > found in the psymtab search that follows the call to > lookup_symbol_aux_minsyms. > > Here's the current control flow, more or less: > > * Search symtabs. > > * Search minsyms. > > ** Maybe then call lookup_symbol_aux with a demangled name as the > 'name' argument, in which case we: > > ** Search symtabs again, with mangled name. > > ** Search minsyms again, with mangled name. > > ** Search psymtabs, with mangled name. > > * Search psymtabs (with demangled name). > > > The 'else' clause is the stuff that I've labeled with two asterisks. > I don't see how the 'search symtabs again' or 'search minsyms again' > parts could ever return anything useful. And the 'search psymtabs, > with mangled name', might accidentally sometimes find the variable > we're looking for; if so, however, the outer 'search psymtabs (with > demangled name)' would have found it as well, and would do so much > more reliably. > > David Carlton > carlton@math.stanford.edu