This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions
Daniel Berlin writes:
> (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.
>