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
- To: Daniel Berlin <dberlin at redhat dot com>
- Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions
- From: David Taylor <taylor at cygnus dot com>
- Date: Fri, 30 Mar 2001 16:49:24 -0500
- cc: gdb-patches at sources dot redhat dot com
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.
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?). At a
minimum there should probably be some sort of explanatory comment.
(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?
Also, should these functions be in here? In dwarf2read.c? Or in a
new file (dwarf2eval.c?)?
(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?
And is it likely that some other symbol reader would someday want a
similar hook? For example, what about dwarf1? Or is dwarf2 likely to
be the only one?