This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- To: Petr Sorfa <petrs at caldera dot com>, Daniel Berlin <dan at dberlin dot org>,Daniel Jacobowitz <drow at mvista dot com>
- Cc: <gdb at sources dot redhat dot com>
- Date: 01 Feb 2002 16:45:25 -0500
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- References: <Pine.LNX.4.44.0201181449580.25029-100000@dberlin.org><npu1tcbply.fsf@zwingli.cygnus.com>
Since it seems that GCC3 is now describing the location of virtual
base classes using complex Dwarf 2 expressions, I guess we should sort
this out quickly. Whoever's idea it was... :)
At the moment, enum address_class does a number of different jobs:
- They distinguish functions, variables, and types (LOC_BLOCK,
LOC_TYPEDEF, etc.)
- They distinguish arguments from local variables (compare LOC_REGISTER
with LOC_REGPARM).
- They mark variables that have been optimized out
(LOC_OPTIMIZED_OUT).
And maybe some other stuff? I just grepped for all uses of
LOC_REGPARM and tried to figure out why the code cared.
In the end, I think we want to have:
- variables, members, and baseclasses able to indicate their locations
using arbitrary functions provided by the debug readers,
- the other data disentangled from the location of the variable
(although I guess "optimized out" really is the `nowhere' answer to
the question, "Where is this variable now?"),
- all the extant address classes represented uniformly using
function pointers
- enum address_class left representing only the kind of entry
(var/func/typedef), and perhaps renamed.
But following the Canticle of St. Cagney, we need to do this in small,
incremental steps, so that at each point we have a GDB which works no
worse than it did before.
Here are the steps, as I see them:
- Get arbitrary Dwarf 2 location expressions working for variables.
Add new members to enum address_class, LOC_COMPUTED and
LOC_COMPUTED_ARG; symbols with this address class refer to some
structure roughly like this:
/* A structure of function pointers describing the location of a
variable, structure member, or structure base class.
These functions' BATON arguments are generic data pointers, holding
whatever data the functions need --- the code which provides this
structure also provides the actual contents of the baton, and
decides its form. However, there may be other rules about where
the baton data must be allocated; whoever is pointing to this
`struct location_funcs' object will know the rules. For example,
when a symbol S's location is LOC_COMPUTED, then
SYMBOL_LOCATION_FUNCS(S) is pointing to a location_funcs structure,
and SYMBOL_LOCATION_BATON(S) is the baton, which must be allocated
on the same obstack as the symbol itself. */
struct location_funcs {
/* Return the value of the variable described by BATON, relative to
the stack frame FRAME. If the variable has been optimized
out, return zero.
If `read_needs_frame (BATON)' is zero, then FRAME may be
zero. */
struct value *(*read_variable) (void *baton, struct frame_info *frame);
/* Return true if we need a frame to find the value of the object
described by BATON. */
int (*read_needs_frame) (void *baton);
/* Write to STREAM a natural-language description of the location of
the object described by BATON. */
int (*describe_location) (void *baton, struct ui_file *stream);
/* Tracepoint support.
Append bytecodes to the tracepoint agent expression AX that push
the address of the object described by BATON. Set VALUE
appropriately. Note --- for objects in registers, this needn't
emit any code; as long as it sets VALUE properly, then the caller
will generate the right code in the process of treating this as
an lvalue or rvalue. */
void (*tracepoint_var_ref) (void *baton,
struct agent_expr *ax,
struct axs_value *value);
};
So dwarf2expr.c (or whatever) will define one of these structures
for location expressions, and some structure for the batons, and
dwarf2read.c will build symbols that refer to them. We could add
support for location lists, too, without touching the rest of GDB.
All code that uses `enum address_class' now will need to be
updated. There will be some changes needed to the generic symbol
building functions that the debug readers use.
(I think the Dwarf 2 location expression interpreter should be in its
own file, since it is going to depend on a lot of stuff that the
normal symbol reader really shouldn't care about --- stack frames,
actual register values, etc.)
We'll need another function like `read_variable' for finding virtual
base classes; I don't know what its arguments should be.
- Same for C++ virtual base classes.
- Same for individual members. (Where is this needed? Don't we just
need it for base classes?)
- Move the "argument vs. local var" information into a separate field
of `struct symbol' and `struct partial_symbol'. LOC_COMPUTED and
LOC_COMPUTED_ARG become the same thing.
- Gradually write location_funcs structures for the other address
classes (offset from FP, etc.). Put the widely useful ones (offset
from FP) someplace generic; put others in the symbol readers that
generate them.
- Once `enum address_class' is left containing only LOC_UNDEF,
LOC_CONST, LOC_BLOCK, LOC_LABEL, LOC_TYPEDEF, rename it to something
more appropriate. :)