Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?

[Daniel Berlin <dan at dberlin dot org>]

On 1 Feb 2002, Jim Blandy wrote:

> 
> 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);

I assume natural language is a codeword for "meant for user only, don't 
try to parse it"?

> 
>       /* 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.  */

Is this always possible without a current address?
IE can the agent bytecode support the fact that for location lists, we 
need to know where we are before we can tell you where the variable is.
One could encode this as a bunch of if's and comparisons if the agent 
bytecode supports them, i guess.

>       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.


Here's a question to think about as we move towards that:
Where should the cache be?

If you are using oft-computed expressions, we should be able to cache them 
if the information they depend on hasn't changed.

Should each thing that implements the functions above handle caching 
internally, or should we put it one level above, and add functions to make 
generic queries like "is this location going to change if the x 
register changes".

Assuming the queries are cheap, you could simply walk the changed 
values in the frame, ask if if any matter, and if not, you don't need 
to redo the calculation/value.

 > > - Once `enum 
address_class' is left containing only LOC_UNDEF,
>   LOC_CONST, LOC_BLOCK, LOC_LABEL, LOC_TYPEDEF, rename it to something
>   more appropriate.  :)
>