[Dwarf-Discuss] PROPOSAL: Constant expressions in location lists

[Caroline Tice]

I've been following this discussion with great interest, as I work
largely in the area of trying to get debuggers (particuarly gdb) to
work "reasonably well" on optimized code (particularly the output from
gcc).

One extremely frustrating problem we run into a lot is that users will
ask to see variables that MUST be there somehow (otherwise the
computation could not be occurring), but gdb insists they are not.
The reason is that the compiler has transformed these variables in
such a way that (currently) there is no way to tell the debugger how
to access these variables.

The two most common cases I have run across are

1).  Given a for-loop of the kind:

      for (i = 0; i < 10; i++) {...}

      gcc converts the loop index variable so that instead of
      counting up from 0 to 9, it counts down from 9 to 0. (It does
      this by using a special register and a special instruction,
      which speeds things up a bit).

  When watching the code execute, the user KNOWS that the loop index
variable has to be around somewhere, but "i" as such has been
optimized away.  In this case it would be nice if DWARF allowed the
compiler to state "reconstruct i by getting the value of such-and-so
register and subtracting that value from 10".  Notice in passing, that
Jim Blandy's suggestion of representing source language expressions is
not helpful in this case because source languages don't let you
specify/access particular registers.  Using the suggestions from some
of the previous emails this might look something like:

        DW_OP_lit10 DW_OP_regx 47  DW_OP_minus  DW_OP_computed_value

2).  Given a boolean/flag variable, you might have some code of the  
form:

      flag = some_function_call ();

      if (flag)
        { ... }
      else
        { ... }

Again, it is obvious that the flag variable's value must be around
somewhere, (especially at the line containing the "if"), but it's
usually not available.  In this case, what gcc usually does is to
compare the result of "some_function_call ()" against 0, and store the
result of the comparison in a special register.  This presents a more
complex problem, because the debugger really can't tell the user the
value of "flag".  But what it *could* tell the user (assuming DWARF
gave it the necessary tools) is something along the lines of:

     (gdb) print flag
      Exact value unavailable.  "flag > 0" is true.

      (or "flag > 0 is false" or whatever the comparison is that
      the compiler actually performed).

This could be represented by something like:

     DW_OP_lit 0 DW_OP_gt DW_OP_regx 51  DW_OP_comparison_value

     where "DW_OP_lit0" is the value against which the
                         compiler performed the comparison,
           "DW_OP_gt" is the type of comparison the compiler performed
           "DW_OP_regx 51" is where the result of the comparison is  
stored
           "DW_OP_comparison_value" marks this as a non-exact value,  
namely
                         the result of a comparison.  Perhaps
                         "DW_OP_indirect_value" would be better?


I am not proposing this as the exact DWARF representation to use; it's
just a rough idea of what I need.

I am sure that there are far more cases where having DWARF be able to
reconstruct (or partially reconstruct) values that the compiler has
transformed or optimized away would be very useful.  These are just
two examples of my most pressing needs, and something for the
committed to consider when (if) they consider an extension to allow
specifying variables that optimizations have made not directly
available.

Since none of the previous discussions on this topic included cases at
all like these, I wanted to point them out.


--  Caroline Tice
ctice at apple.com