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

[Jim Blandy <jimb at zwingli dot cygnus dot 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.  :)