From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9283 invoked by alias); 11 Sep 2002 00:31:25 -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 9276 invoked from network); 11 Sep 2002 00:31:24 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 11 Sep 2002 00:31:24 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17owLl-0006Bw-00; Tue, 10 Sep 2002 20:31:25 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17ovPo-000374-00; Tue, 10 Sep 2002 20:31:32 -0400 Date: Tue, 10 Sep 2002 17:31:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb Subject: Re: struct environment Message-ID: <20020911003132.GA11810@nevyn.them.org> Mail-Followup-To: David Carlton , gdb References: <20020906150620.GA19200@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00091.txt.bz2 On Tue, Sep 10, 2002 at 05:25:56PM -0700, David Carlton wrote: > 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? My memory is hazy, but if you search the archives I suspect you'll see hints that this all can be deleted. I believe the SYMBOL_ALIASES stuff has all died; it was never in a standard FSF GCC, just in a Cygnus product. We'll need to handle something along these lines in the fortold day of wonders, when we actually have thought of something clever to do when debugging inlined functions; but for now I doubt anyone would miss this. Can anyone confirm my memory? > > /* 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 > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer