Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
> DW_OP_implicit_value and DW_OP_stack_value produce values (that is > R-values), not locations. I might be able to read > DW_OP_implicit_pointer as providing a location; I'm not sure. No, they don't produce a value. The expression that precedes them produces a value, and these operators produce a location description for that value. > As I said, values and locations are muddled. If you think that a > variable which has been eliminated has a location which is described by > a DW_OP_implicit_value, then we aren't working with the same definition > of "location". Evidently not. For values that don't have a location, we have these operators that provide a location description anyway. Even though they're not real locations in the sense of existing in memory or a register, they are locations in the sense that they are described by a location description. Perhaps it would help to think of "locations" as what you think of as locations, and "location descriptions" as something a bit more general. A location description can describe a real location, or it can describe something more ethereal. > This doesn't work with any of the Implicit Location Descriptions, > because there isn't any "there" there. They don't result in locations; > they give the values which would be found if the variable did exist. So > they implicitly perform the dereference operation. Quite the opposite; they perform the inverse of a dereference operation. They provide something at the level of a location description that can be dereferenced but has no other purpose. -cary ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
On 3/23/20 3:58 PM, Cary Coutant via Dwarf-Discuss wrote: 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. Strongly disagree. The whole point of an implicit location description is to give a (pseudo/virtual) location to a value that has no location. A DWARF *expression* has no use for these operators. DW_OP_implicit_value and DW_OP_stack_value produce values (that is R-values), not locations. I might be able to read DW_OP_implicit_pointer as providing a location; I'm not sure. As I said, values and locations are muddled. If you think that a variable which has been eliminated has a location which is described by a DW_OP_implicit_value, then we aren't working with the same definition of "location". The problem is that the basic DWARF concept is that a variable has a location and that you can fetch its values from this location. Thus, we expect to be able to evaluate a location description and dereference it to get a value. Similarly, you can change a variable's value by modifying its location. This dereference or modification may be a bit complicated if DW_OP_piece is involved, but the operation is symmetric. This I might call a "real" location description. This doesn't work with any of the Implicit Location Descriptions, because there isn't any "there" there. They don't result in locations; they give the values which would be found if the variable did exist. So they implicitly perform the dereference operation. But, in contrast to "real" location descriptions, the operation is not symmetric, you can't change the variable's value. ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
> 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. Strongly disagree. The whole point of an implicit location description is to give a (pseudo/virtual) location to a value that has no location. A DWARF *expression* has no use for these operators. > 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. Other than that first sentence of 2.5, I think they are pretty clearly distinguished. Location descriptions, covered by Section 2.6, are built on top of DWARF expressions, and provide additional operators for specifying locations other than simple memory locations. -cary ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Segment selectors for Harvard architectures
Not to derail this thread, but another thing that might be worth checking is: should debug_aranges include non-code addresses. GCC's don't, Clang's do. Sounds like Clang's correct, but GCC is sort of the defacto standard DWARF producer, so might be worth getting an authoritative statement/clarified wording here. (especially since it's intended for lookup, so it's important what is/isn't included, much like debug_names - not so open to leaving it up to "quality of implementation") On Thu, Mar 19, 2020 at 11:05 AM Robinson, Paul via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > This recently came up in the LLVM project. Harvard architectures > put code and data into separate address spaces, but those spaces > are not explicit; instructions that load/store memory implicitly > use the data space, while things like taking a function address or > doing indirect branches will implicitly use the code space. This > doubles the effective size of memory without consuming an address > bit, as well as having other secondary benefits like not allowing > self-modifying code. > > Nearly all of the DWARF information does not need to distinguish > between code and address spaces, because it's easy to derive that > from context. Addresses in the line table or a range list will be > code addresses; in .debug_info, addresses of code elements will be > code addresses, while variables will be data addresses. And so on. > > This only seems to break down in the .debug_aranges section, which > records both data and code addresses without any context to let a > consumer know which is what. In a flat-address architecture, no > distinction is needed; in a segmented architecture, there will be > a segment selector as part of any address, and that includes the > .debug_aranges section. What about for Harvard architectures? > > What I suggested in the LLVM project is that .debug_aranges would > have a 1-byte segment selector and use some trivial scheme such as > 0=code, 1=data to distinguish what kind of address it is. Other > DWARF sections wouldn't need a selector because they can all use > context to figure it out; this avoids the size overhead of using > segment selectors everywhere else. > > Pavel Labath pointed out that this seems inconsistent and might > make consumers unhappy; segment selectors are described as a > characteristic of the target architecture, so having them in one > place and not others might look suspicious. IMO it's a reasonable > "permissive" use of the existing DWARF structures, but it seemed > worth asking here. > > Does this (segment selector only in .debug_aranges) sound okay? > Should there be non-normative text or a wiki description of this? > Do we want to codify the 0=code 1=data use of segment selectors > for all Harvard architectures (that don't otherwise have explicit > segements) so that this doesn't have to be set by ABI committees? > > I'm willing to write up whatever needs writing up, either as a > proposal or as a wiki entry. > > Thanks, > --paulr > > ___ > 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
Re: [Dwarf-Discuss] Segment selectors for Harvard architectures
Paul, I haven't needed to contend with this issue. But as I was looking over the standard, this was my initial gut reaction too: use the segment selectors. This use actually does seem like it's a characteristic of the target architecture to me. You started the discussion with "Harvard architectures". DWARF does permit architectures to specify aspects of their DWARF description, after all. I can't recall it ever being done *formally*, but it's been done informally for every architecture that uses DWARF. At a bare minimum, register encodings. And usually you have to root around in somebody else's source code to find it. This one has a slightly higher chance of breaking a consumer, if that consumer was written not to tolerate the segment selectors. But I think it would be fair to put any such blame on the consumer in that case. If the consumer doesn't die with a SIGSEGV, then it might ignore the segments. And then it would be no worse off than now. On Thu, Mar 19, 2020 at 06:05:16PM +, Dwarf Discussion wrote: > This recently came up in the LLVM project. Harvard architectures > put code and data into separate address spaces, but those spaces > are not explicit; instructions that load/store memory implicitly > use the data space, while things like taking a function address or > doing indirect branches will implicitly use the code space. This > doubles the effective size of memory without consuming an address > bit, as well as having other secondary benefits like not allowing > self-modifying code. > > Nearly all of the DWARF information does not need to distinguish > between code and address spaces, because it's easy to derive that > from context. Addresses in the line table or a range list will be > code addresses; in .debug_info, addresses of code elements will be > code addresses, while variables will be data addresses. And so on. > > This only seems to break down in the .debug_aranges section, which > records both data and code addresses without any context to let a > consumer know which is what. In a flat-address architecture, no > distinction is needed; in a segmented architecture, there will be > a segment selector as part of any address, and that includes the > .debug_aranges section. What about for Harvard architectures? > > What I suggested in the LLVM project is that .debug_aranges would > have a 1-byte segment selector and use some trivial scheme such as > 0=code, 1=data to distinguish what kind of address it is. Other > DWARF sections wouldn't need a selector because they can all use > context to figure it out; this avoids the size overhead of using > segment selectors everywhere else. > > Pavel Labath pointed out that this seems inconsistent and might > make consumers unhappy; segment selectors are described as a > characteristic of the target architecture, so having them in one > place and not others might look suspicious. IMO it's a reasonable > "permissive" use of the existing DWARF structures, but it seemed > worth asking here. > > Does this (segment selector only in .debug_aranges) sound okay? > Should there be non-normative text or a wiki description of this? > Do we want to codify the 0=code 1=data use of segment selectors > for all Harvard architectures (that don't otherwise have explicit > segements) so that this doesn't have to be set by ABI committees? > > I'm willing to write up whatever needs writing up, either as a > proposal or as a wiki entry. > > Thanks, > --paulr > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org -- Todd Allen Concurrent Real-Time ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
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 On Behalf > > > Of Adrian Prantl via Dwarf-Discuss > > > > On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss > > 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 >
Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
On 3/23/20 6:28 AM, Robinson, Paul via Dwarf-Discuss wrote: From: Dwarf-Discuss On Behalf Of Adrian Prantl via Dwarf-Discuss On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss 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
Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?
> -Original Message- > From: Dwarf-Discuss On Behalf > Of Adrian Prantl via Dwarf-Discuss > Sent: Friday, March 20, 2020 1:29 PM > To: Michael Eager > Cc: dwarf-discuss@lists.dwarfstd.org > Subject: Re: [Dwarf-Discuss] Use of Location Description operations in > DWARF Expressions? > > > > > On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss 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. --paulr > That distinction is important, because if there is a *technical* reason > for not supporting them we should refrain from implementing this in LLVM. > But if there isn't, there is no harm done in implementing it as an > extension, and DWARF consumers that don't support it can just ignore these > expressions and return N/A. > > -- adrian > ___ > 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
