Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions

[Daniel Berlin <dberlin at redhat dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:

> > So the code doesn't belong in dwarf2read.c.  dwarf2read.c is a symbol
> > reader. dwarf2 location expressions are a way of describing variable
> > locations.  The other code to process the current gdb address
> > classes/locations is in findvar.c, so that's where i put it.
> 
> No.
> 
>     if (frame == NULL)
>       frame = selected_frame;
> !   if (SYMBOL_DWARF2_LOC (var) != NULL)
> !     return evaluate_dwarf2_locdesc (var, frame, (struct dwarf_block *)
> SYMBOL_DWARF2_LOC (var),
> SYMBOL_TYPE (var));
>     switch (SYMBOL_CLASS (var))
>       {
>       case LOC_CONST:
> 
> I would have expected something like:
> 
> 	if (this symbol's location is computed dynamically) then
> 	   return var->compute_location_dynamically (frame);
> 
> where that ``compute_location_dynamically'' was a function supplied by
> dwarf2read.c.

Why would dwarf2read.c supply it? It's not part of the symbol
reader. It is the location of the symbol. Anything can fill in that
particular field of the symbol structure.

It's no different a location than LOC_CONST, LOC_REGPARM, etc. It just
happens to be a bunch of operations that get evaluated, rather than 1
or 2 fixed ones.

> 
> For this starts to make sense, I suspect it needs to be given some
> additional context - namely where in dwarf2read.c things are also going
> to be changed.

Make sense?
In what way?

> 
> 	Andrew

-- 
I looked out my apartment window, and I saw a bird wearing
sneakers and a button saying, "I ain't flying no where."  I
said, "What's your problem buddy?"  He said, "I'm sick of this
stuff -- winter here, summer there, winter here, summer there.