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

[Jim Blandy]

On Jan 6, 2008 7:38 PM, Michael Eager <eager at eagercon.com> wrote:
> > There's no necessary restriction on what types of values a compiler
> > might be able to optimize out; in the most general case, the values to
> > be computed could be structures, large floating-point types, etc.  So
> > DWARF needs to be able to describe how to compute values with
> > arbitrary source types.
>
> No, you only need to be able to interpret the instructions given
> by the compiler to compute a machine value.  This does not require
> that a debugger have a source language interpreter, and in particular,
> it doesn't require DWARF to be able to describe arbitrary source
> types.

I'm not sure I follow.  If the task is to be able to recompute values
of variables that have been optimized out, and those variables could
potentially have any type, then DWARF needs to be able to express how
to compute the run-time, target representations of values of arbitrary
type.

> > DWARF does have DWARF expressions, but their semantics were
> > deliberately restricted to computing address-sized values, to keep the
> > specification simple and focussed.  We're now considering using DWARF
> > expressions to compute (potentially) every type of value expressible
> > in the source language.
>
> This seems to exaggerate the problem.  You don't need to compute
> "every value expressible in the source".  Instead you need to compute
> every value expressible in the machine.  Machines have a very narrow
> range of types, usually two: binary integer and floating point.  And
> it may not be necessary to even compute that range -- all you care
> about is bit patterns.

Yes --- but this isn't a simplification.  If the variable that has
been optimized out has a class type (which I'll bet C++ compilers
dealing with STL code do now), then the compiler would need to produce
DWARF expressions that yield the run-time, target representation
values having that class type.

> > Following this approach, If the compiler had optimized out a
> > floating-point value, but knew how to recompute it if desired, and
> > wished to express this in DWARF, the compiler would need to produce a
> > DWARF expression that would yield the appropriate floating-point
> > value, in target format.
>
> That's true, but it doesn't necessarily follow that DWARF expressions
> need to perform floating point computations.
>
> Let's say you had the following snippet of code:
>
>      float pi(void) {
>         float val = 3.14159;
>         return val;
>      }
>
> A reasonable compiler would discard 'val' resulting in the debugger
> giving a message saying that the value was not available.  To
> reconstruct the value of this discarded variable, all you need to
> do is generate the bit pattern which has this value: 0x400921fa.

This case is already covered by DW_AT_const_value.  Presenting
constant bit patterns is no trouble, I agree.  I was told up-thread
that the case where values do actually need to be computed is what
we're concerned with here.

> Essentially, your suggestion is to turn DWARF into a standardized
> intermediate representation, describing all of the features of the
> source.  That's beyond the scope of a debugging format.

That wasn't my proposal at all.  It was much less ambitious than that.
I don't think I explained myself well.  Having made a second try, I'll
drop the suggestion.


> As indicated above, it isn't clear that you need to implement
> floating point operations in DWARF expressions.  But even if you
> did, this is not by any means a task of "ridiculous complexity".
> It would require perhaps a half-dozen well defined operations
> which would operate on the top of the expression stack.

If we extend the DWARF expression stack to hold floating-point values,
of various widths, then that would address the problem.  I think it
would be more than a half-dozen operations, but still quite practical.
I think we'll end up wanting to expand our set of arithmetic operators
as well.