From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28853 invoked by alias); 24 Feb 2003 18:04:13 -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 28830 invoked from network); 24 Feb 2003 18:04:12 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 24 Feb 2003 18:04:12 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1OI3tR18243; Mon, 24 Feb 2003 10:03:55 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy Subject: Re: [rfa] delete lookup_symbol_aux_minsyms References: <20030222205011.GA25494@nevyn.them.org> From: David Carlton Date: Mon, 24 Feb 2003 18:04:00 -0000 In-Reply-To: <20030222205011.GA25494@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00589.txt.bz2 On Sat, 22 Feb 2003 15:50:11 -0500, Daniel Jacobowitz said: > On Sat, Feb 22, 2003 at 11:54:40AM -0800, David Carlton wrote: >> So what's the conclusion? Performance considerations don't seem to >> give a clear answer. So we should go with whatever's cleanest. My >> recommendation: >> >> * Delete the 'else' clause: it might cause correctness problems. >> >> * Comment out the remaining part of lookup_symbol_aux_minsyms: if >> somebody comes up with a situation where we spend lots of time >> searching for functions that aren't in a loaded symtab, we can >> consider uncommenting it and adding it back in. > I'm pretty sure the answer is "none at all" based on skimming the > code, but what affect does removing lookup_symbol_aux_minsyms have > when looking for something which turns out not to have debugging > info? lookup_symbol would fail, so it doesn't matter - is that > right? That's right: lookup_symbol tries to find symbols, so if a function doesn't have debugging info, then lookup_symbol will return NULL (unless we're in some sort of bizarre situation like having a static function elsewhere with the same name), at which point it's the caller's responsibility to call lookup_minimal_symbol if the caller is in a position to deal with minimal symbols instead of symbols. And lookup_symbol would have returned NULL either before or after my patch: the call to 'find_pc_sect_symtab' would have failed. > I don't know if I like this comment-out-part-delete-part business; > if we don't want the function, let's kill it. It's not my first choice, either, but Elena has shown a preference in the past for commenting out code like this instead of deleting it. (C.f. the already commented-out bit in lookup_symbol_aux.) This seems to me a situation where it's not worth arguing about it. However, if Elena would rather delete it, I'd be happy to go along with that, too. David Carlton carlton@math.stanford.edu