This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: struct environment


On Tue, Sep 10, 2002 at 05:25:56PM -0700, David Carlton wrote:
> On Fri, 6 Sep 2002 11:06:20 -0400, Daniel Jacobowitz <drow@mvista.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]