[Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

[Todd Allen]

I recall this being intentional as well.  This is how I think of these items.
And this is just the gist of things.  I didn't put on my ABI Lawyer hat for
this:

A DWARF expression is a stack machine that evaluates to a value.

A location description describes the "location" of an object.  A "location" is
pure concept here, and doesn't necessarily require any physical location.  It
can be:
 * In memory at an address: It has a DWARF expression which computes the
   start address.
 * In a register: DW_OP_regN, DW_OP_regx.  No locdesc needed.
 * Nowhere, but with a known value: DW_OP_implicit_value, DW_OP_stack_value.
   I think of this as being an ephemeral "location", which in concrete terms
   would be in a buffer in the debugger or some other consumer.  There's a
   DWARF expression which computes the value.
 * Nowhere, but where it's an optimized-away pointer, and its designated
   (pointed-to) value is a known value, much like above.
 * Spread out across multiple distinct locations: DW_OP_piece's, where each
   piece can be any one of the above.
Oh, and one more:
 * Nowhere at all.  Go fish.

So locdescs can use a DWARF expression for a couple different purposes, or even
multiple DWARF expressions.  But they have additional operators for additional
cases (e.g. registers), and for "glue" (DW_OP_piece).

Conversely, DWARF expressions cannot use any of the locdesc special operators or
"glue".

But, of course, there could be use cases where some of these would make sense in
a DWARF expression, and we just didn't think of it.  Nothing springs to my mind
right now...  But if you have a compelling case, we certainly could move some of
those special/glue operators from the locdesc category to the DWARF expression
category.

It think it feels a little blurry only because locdescs came first, and then we
co-opted them for DWARF expressions, and restricted the use of certain operators
in that case.  And then it eventually changed into what we have now.  But a lot
of us remember the history, which creates that blur.

-- 
Todd Allen
Concurrent Real-Time

On Mon, Mar 23, 2020 at 12:04:58PM -0700, Dwarf Discussion wrote:
> On 3/23/20 6:28 AM, Robinson, Paul via Dwarf-Discuss wrote:
> > > From: Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org> On Behalf
> > > Of Adrian Prantl via Dwarf-Discuss
> > > > On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss <dwarf-
> > > discuss at lists.dwarfstd.org> wrote:
> > > > 
> > > > My reading of sections 2.5 & 2.6 is that you cannot have a DW_OP_piece
> > > in an DWARF expression.
> > > > 
> > > 
> > > I wonder if this is an intentional part of the design because of
> > > ambiguity/correctness issues or is this just something that happens to
> > > fall out of the way the text is worded? I can see how such a restriction
> > > might simplify DWARF consumers, but it also seems like an arbitrary
> > > restriction for which there may not be a technical reason.
> > 
> > My intuition (clearly I wasn't there at the time) is that this is like
> > a C expression being an rvalue (DWARF expression) or lvalue (location
> > description).  Values and locations aren't the same thing.
> 
> It is somewhat an L-value vs R-value issue.
> 
> You can craft a DWARF expression to extract a value (an R-value) from
> arbitrary memory locations or registers (for example, using DW_OP_and,
> DW_OP_sh?, etc.) and place it on the top of the stack.  A DW_OP_piece
> operator doesn't do this.  (There might be value in an operator which
> extracts a value from a composite location.)
> 
> A location (an L-value) which includes potentially multiple register or
> memory locations and multiple DW_OP_piece or DW_OP_bit_piece operations
> can't be evaluated by a simple stack-based expression interpreter.
> 
> The design is intentional, AFAIK, not accidental.
> 
> I think that the description has become a bit less clear with the addition
> of the Implicit Location Descriptions in Section 2.6.1.1.4, which do compute
> values, rather than locations.  Perhaps these should have been described in
> Section 2.5 as parts of a DWARF expression, not as parts of a Location
> Description.
> 
> The description (and implementation) of DWARF expressions and locations are
> somewhat muddled together.  This can be seen in the first sentence of
> Section 2.5:
>    DWARF expressions describe how to compute a value or specify a
>    location.
> A clearer definition would specify that the DWARF expression only computes a
> value, and leaving what that value means (e.g., register/memory contents,
> arbitrary computation, memory address) to the context in which the
> expression is used.  A more precise definition of a location, especially a
> composite location, would help.
> 
> Part of this is historical, with the expression evaluation initially used to
> compute a memory address and then extended to accommodate composite
> locations and further extended to compute arbitrary values. These extensions
> were in divergent directions, affecting both location composition and value
> computation.  It would have been better if the two concepts were clearly
> distinguished.
> 
> -- 
> Michael Eager
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org