dwarf3 and location expressions et.al.

[Andrew Cagney <ac131313 at cygnus dot com>]

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