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-boun...@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- > > > disc...@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@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
