This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
dwarf3 and location expressions et.al.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: gdb at sources dot redhat dot com
- Date: Sat, 16 Mar 2002 13:32:24 -0500
- Subject: dwarf3 and location expressions et.al.
Jim,
I've been looking through your location expression post:
> 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);
>
> };
I'm wondering if the thing to do is to map (baton, frame) onto a
``struct expression'' rather than directly onto a ``struct value''. I'm
wondering of the CFI stuff should also do this.
Once you have an expression for a variable, it should be possible to use
existing infrastructure to evaluate or encode it.
This also has the advantage of keeping expresion evaluation in one place
- if the expression evaluation is ever made asynchronous then there is
only one evaluator to fix for instance.
--
Digging around to see how dwarf2 handles things, I suspect that getting
``struct expression'' and ``struct value'' involved will flush out some
long standing problems.
For instance, GDB currently assumes that a register ``struct value'' can
only be split across adjacent registers (e.g., r0:r1) (well mostly, the
mips does pull a few small rabbits out of its hat). Part of the above
will mean modifying ``struct value'' so that it can describe a value
that has pieces in random locations. Looks like it also needs to
describe something that has values in multiple locations simultaneously
(Ulgh!).
Another good thing is that this is also something that can be separated
out and fixed independently.
Andrew