From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30210 invoked by alias); 24 Dec 2002 06:59: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 30203 invoked from network); 24 Dec 2002 06:59:51 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by 209.249.29.67 with SMTP; 24 Dec 2002 06:59:51 -0000 Received: (qmail 97814 invoked by uid 19025); 24 Dec 2002 06:59:39 -0000 Date: Tue, 24 Dec 2002 01:56:00 -0000 From: Jason Molenda To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy Subject: Re: [rfa] more lookup_symbol_aux_minsyms futzing Message-ID: <20021223225939.A94340@molenda.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from carlton@math.stanford.edu on Mon, Dec 23, 2002 at 10:21:12AM -0800 X-SW-Source: 2002-12/txt/msg00662.txt.bz2 Hi David, On Mon, Dec 23, 2002 at 10:21:12AM -0800, David Carlton wrote: > Here's another patch involving lookup_symbol_aux_minsyms. We (Apple) shipped our latest devtools release based on the Octoberish gdb top-of-tree and I spent a good bit of today tracking over this same exactly section of code for a customer's problem. I was going to send out a note once I understood how it'd all happened, but it sounds exactly like what you describe here. It's been a good while since I've looked at this code, and my notes from today's debugging are all at work, so please excuse any especially dumb misstatements. :) lookup_symbol_aux is called with a C++ unmanged+mangled name, lookup_symbol_aux_symtabs doesn't get a match because we've only read in the psymtab at this point; lookup_symbol_aux_minsyms calls lookup_symbol_aux with the mangled+mangled names as a last resort, and something lame happened from there on (but I don't remember exactly...) -- and eventually we call lookup_symbol_aux_psymtabs with the mangled+mangled names -- lookup_partial_symbol gets passed a mangled name, says there is a match because psymtabs have only mangled names. We parse in the symtab, then we do lookup_block_symbol with the mangled name, but the lookup_block_symbol hash of the mangled name doesn't match that of the unmangled name, so we issue the error error ("Internal: %s symbol `%s' found in %s psymtab but not in symtab.\n%s may be an inlined function, or may be a template function\n(if a template, try specifying an instantiation: %s).", block_index == GLOBAL_BLOCK ? "global" : "static", It also seemed incorrect for lookup_symbol_aux to call lookup_symbol_aux_minsyms before lookup_symbol_aux_psymtabs, but I'm guessing this is done on purpose based on this comment in your patch - > + /* We found a minimal symbol in spite of not finding a > + symbol. This probably means that the symbol in question > + is in a partial symbol table that hasn't been loaded, but > + it may mean that it's from code compiled without -g. > + Partial symbol table searches are kind of expensive; if > + the symbol corresponds to a function, we can find the > + appropriate symtab more quickly by calling > + find_pc_sect_symtab, so let's try that. */ > + The test case I have from the customer is a nice little thing but it pulls in a big gop of Apple system libraries so I don't know how easy it'd be to make a portable version. At the very least, I'll be looking at this tomorrow and should know better how we can fix it up. For what it's worth, everyone at Apple has been really excited by the work you've been doing, David. Anyone willing to wade into decode_line_1 and do something other than increase entropy has my respect. :-) Jason