From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7442 invoked by alias); 11 Sep 2002 00:25:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7428 invoked from network); 11 Sep 2002 00:25:58 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 11 Sep 2002 00:25:58 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8B0Puj00417; Tue, 10 Sep 2002 17:25:56 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb Subject: Re: struct environment References: <20020906150620.GA19200@nevyn.them.org> Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Tue, 10 Sep 2002 17:25:00 -0000 In-Reply-To: <20020906150620.GA19200@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-09/txt/msg00090.txt.bz2 On Fri, 6 Sep 2002 11:06:20 -0400, Daniel Jacobowitz said: > On Thu, Sep 05, 2002 at 01:50:40PM -0700, David Carlton wrote: >> * There should be a shallow lookup function, i.e. one that looks up a >> symbol just in one environment, without going up to a parent >> environment. (The latter will get added in once we get to >> converting over the global environment.) Maybe >> >> struct symbol *env_lookup_shallow(struct environment *, >> const char *); > You may need more information than this. Sometimes > lookup_block_symbol needs to look up the symbol (i.e. demangled) > which has a particular mangled name - this is a wart and not one I'm > fond of but it isn't quite ready to die yet. Fair enough; for now, that function has the exact same arguments as lookup_block_symbol (i.e. including the demangled name and the namespace). But, speaking of warts in lookup_block_symbol, what's going on with this code? /* If SYM has aliases, then use any alias that is active at the current PC. If no alias is active at the current PC, then use the main symbol. ?!? Is checking the current pc correct? Is this routine ever called to look up a symbol from another context? FIXME: No, it's not correct. If someone sets a conditional breakpoint at an address, then the breakpoint's `struct expression' should refer to the `struct symbol' appropriate for the breakpoint's address, which may not be the PC. Even if it were never called from another context, it's totally bizarre for lookup_symbol's behavior to depend on the value of the inferior's current PC. We should pass in the appropriate PC as well as the block. The interface to lookup_symbol should change to require the caller to provide a PC. */ if (SYMBOL_ALIASES (sym)) sym = find_active_alias (sym, read_pc ()); sym_found = sym; if (SYMBOL_CLASS (sym) != LOC_ARG && SYMBOL_CLASS (sym) != LOC_LOCAL_ARG && SYMBOL_CLASS (sym) != LOC_REF_ARG && SYMBOL_CLASS (sym) != LOC_REGPARM && SYMBOL_CLASS (sym) != LOC_REGPARM_ADDR && SYMBOL_CLASS (sym) != LOC_BASEREG_ARG) { break; } Is the SYMBOL_ALIASES bit some sort of stabs mess? And is that if expression an attempt to make sure that function arguments whose names are shadowed by local variables don't get returned? For now, I'm planning just to copy all that to env_lookup_shallow, but I do wish I understood a little better what it's doing. David Carlton carlton@math.stanford.edu