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

[Daniel Berlin <dberlin at redhat dot com>]

(If you aren't familiar, the address_class enum lists the ways you can
describe the location of a symbol. that's what i'm talking about when
i say address classes)
David Taylor <taylor@cygnus.com> writes:

>     Date: Fri, 30 Mar 2001 14:10:46 -0500 (EST)
>     From: Daniel Berlin <dberlin@redhat.com>
> 
>     This patch adds a place in the symbol structure to store the dwarf2
>     location (an upcoming dwarf2read huge rewrite patch uses it), an
>     evaluation maachine to findvar.c, and has read_var_value use the dwarf2
>     location if it's available.
> 
>     NOte that in struct d2_location, in the symtab.h patch, that framlocdesc
>     cannot be unioned with locdesc, because the symbol providing the frame
>     location description  usually has it's own real location.
> 
>     Currently, because GDB makes no use of the frame unwind info, etc, I
>     evaluate the frame pointer location expression for whatever is providing
>     it for the thing we are trying to evaluate, rather than rely what GDB
>     tells us the frame pointer is.
> 
> I have read that "sentence" multiple times and I still  don't know what
> you are trying to say.  Sorry.

I'm saying currently, the frame base in dwarf2 more descriptive than
the frame pointer in the frame info we have. 

> 
>     Yes, it's currently pointless to do this,  it's just future proofing, and
>     what we are supposed to do, anyway.
> 
>     This patch will have no effect whatosever without the dwarf2read.c
>     rewrite, but it won't break anything, neither, so i sepereated it out and
>     am submitting it now.
>     --Dan
>     2001-03-30  Daniel Berlin  <dberlin@redhat.com>
> 
> 	    * symtab.h (address_class): Add LOC_DWARF2_EXPRESSION.
> 	    (struct symbol): Add struct d2_location to store dwarf2
> 	    location expressions.
> 	    (SYMBOL_DWARF2_LOCATION, SYMBOL_DWARF2_FRAME_LOCATION): New macros.
> 
> 	    * findvar.c (read_leb128): New function, read leb128 data from a
> 	    buffer.
> 
> I don't know what leb128 data is (and I doubt that I'm alone).  I
> suspect that it is something dwarf of dwarf2 specific and that this
> function really belongs in another file (dwarf2read.c maybe?).

LEB128 = Little endian base 128
There is one in there. But we can't use it. It expects to be passed
bfd's .
> At a
> minimum there should probably be some sort of explanatory comment.
Sure.
> 
> 	    (evaluate_dwarf2_locdesc): New function, evaluate a given
> 	    dwarf2 location description.
> 
> This is a very dwarf2 specific change to findvar.c.  What happens if
> something other than dwarf2 is in use?

Um, if it doesn't have a dwarf2 location for the symbol, it just does
what it used to.
> 
> Also, should these functions be in here?  In dwarf2read.c?  Or in a
> new file (dwarf2eval.c?)?
Maybe dwarf2eval, but all the code it's related to is in findvar.c. 

I think you might not quite be understanding what dwarf2 location
expressions/lists are.

They are a way of describing where something is, over it's
lifetime (lists are, expressions are the location over a specific
range. So location lists are simply lists of location expressions, and
the associated address range where that expression is valid). However,
they are much more descriptive than GDB's current 
support for address classes (IE LOC_BASEPARM, etc), and thus,
occasionally we hit ones we can't transform into GDB's other simple
address classes.
It would also be flat out impossible to support location lists, since
gdb's address classes only expect a symbol to be at one location, over
it's lifetime.  So in order to be able to support optimized code
debugging, etc, you need to be able to evaluate the dwarf2 location
list at runtime, to get the address of a particular symbol, at a
particular time.

In fact, dwarf2 location expressions are actually a turing complete
language.  They are evaluated by a stack machine.

If you still aren't grasping it, let me give you an example:

Let's say we have a very simple c file

test.c:


int main(int argc, char *argv[])
{
        int a;
        a=5;
}

If you compile this file with dwarf2 info, the location of a will be
described (most likely) as the location expression "DW_OP_fbreg 8".

When we read the dwarf2 info, we currently try to convert "DW_OP_fbreg
8" into a gdb address class/location, which in this case, is
LOC_BASEREG, SYMBOL_BASEREG(x) = FP_REGNUM, SYMBOL_VALUE(x) = 8 (i'm
doin this from memory, it's probably completely wrong, but i'm just
trying to show something, not be absolutely correct).

If all of these location expression opcodes were simple, we wouldn't
have a problem (we also wouldn't be able to describe things anywhere
near as well as we could).  However, you also have opcodes like
DW_OP_deref, which is supposed to take the top of the current
dwarf2 location machine stack, dereference as if it was a pointer, and
push  the resulting value back onto the top of the stack.  Obviously,
since we don't have access to target memory at symbol reading time, we
can't do this (their is currently a hack that lets us do it if
DW_OP_deref is the last expression). This is because we are expected
to be able to evaluate them at runtime, but because gdb had no way of
evaluating them until how, we had to settle for trying to convert it
into something gdb could handle, and as they get more complex, or when
you try to do something that needs the expressive power, you fail.
We can't even come close to the expressive power with the other
address classes.  There are things like DW_OP_piece that let you say
"the first byte of this variable is in in this place, the next 2 bytes
are here, the last byte is here", etc.  
As I said, it's a turing complete language. 

Keep in mind, the above is just a single location expression. 
Location lists allow you to fully describe the lifetime of even a
variable in optimized code, by associating expressions with ranges of
PC's. 

This code evaluates dwarf2 location expressions to get the location of
a variable, if a symbol has one.  This is used in preference to using the
less expressive way gdb currently supports.

All i've done is add a new way to describe the location of a variable,
and the associated way to evaluate that description.

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.


> 
> 	    (read_var_value): Use the dwarf2 location expression if it's available.
> 
> How do you know that the location expression is NULL when you haven't
> set it -- in particular, what's to prevent it from having garbage in
> it?
Because the symbol gets memset to 0.

> 
> And is it likely that some other symbol reader would someday want a
> similar hook?
It's not a hook really.
The dwarf2reader never calls it, is has no relation to symbol reading.

It is related to describing the location of a variable at runtime.

>  For example, what about dwarf1?
Nope
>   Or is dwarf2 likely to be the only one?

No. DWARF2 is the only symbol format i know of which has support for
something as expressive as location expressions/lists.

GCC uses DWARF2 call frame annotation (which is location lists paired
with registers to tell you were a given register is at a given pc) to
do it's exceptions, for instance.  

If we ever want to be able to use the unwind info or call frame info
to be able to do optimized code debugging without much trouble, we
need to be able to evaluate the expressions.

If it helps, pretend the word DWARF2 appears nowhere in the
patch. There is no relation to the symbol reader.

I could convert the stabs reader to use this way of describing
locations, there's just no point (since stabs's locations aren't more
expressive than what gdb supports).

-- 
I play the harmonica.  The only way I can play is if I get my
car going really fast, and stick it out the window.  I've been
arrested three times for practicing.