From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22198 invoked by alias); 11 Oct 2002 16:31:16 -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 22151 invoked from network); 11 Oct 2002 16:31:14 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 11 Oct 2002 16:31:14 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9BGV6r11970; Fri, 11 Oct 2002 09:31:06 -0700 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 Subject: Re: [drow-cplus-branch] lookup_symbol_aux refactoring References: <20021011161643.GA2862@nevyn.them.org> From: David Carlton Date: Fri, 11 Oct 2002 09:31:00 -0000 In-Reply-To: <20021011161643.GA2862@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: 2002-10/txt/msg00238.txt.bz2 On Fri, 11 Oct 2002 12:16:43 -0400, Daniel Jacobowitz said: > On Fri, Oct 11, 2002 at 09:07:51AM -0700, David Carlton wrote: >> Is it okay if I commit the lookup_symbol_aux refactoring from >> to >> drow-cplus-branch? I've got some patches to symbol table lookup to >> handle namespace stuff that are almost ready (I just want to add some >> testcases), and they'll be a lot cleaner if I get this part of them >> out of the way first. > Hmm... yes, this will be useful for me, too. The only bit I'm nervous > about is the changed search order, but we can update this to match > whatever goes in mainline when your patch is approved. Please do. Done. Yeah, I'm not convinced that the changed search order is ultimately the correct thing to do either. What is important for me right now is to have an easy way to look up a symbol in the global environment. Unfortunately, the way minimal symbol lookup is currently handled screws that up, because it will use static symbols as a fallback measure. So ultimately that will have to get sorted out, and we can go with whatever solution is adopted on the mainline. And I honestly have no idea what that solution will be: it seems to me that trying to use all three of symtabs, psymtabs, and minimal symbols is probably redundant, but maybe I'm missing something and even if they are I don't have a solid feeling for the best way to remove some of the redundancy. For now, I'm adopting the tactic of making sure that things work well if there's proper debugging info but also making the code modular enough that that aspect of the search strategy will be easy to change. David Carlton carlton@math.stanford.edu