On Wed, 2014-04-02 at 08:35 -0700, Michael Eager wrote: > On 04/02/14 03:43, Mark Wielaard wrote: > > On Tue, 2014-04-01 at 18:42 -0700, Michael Eager wrote: > >> On 04/01/14 13:54, Mark Wielaard wrote: > >> > >>> What about using the presence of a DW_AT_external attribute on the data > >>> object that has a single location expression to know whether the described > >>> location is valid/visible outside of the enclosing lexical scope? > >>> > >>> Using that or some new flag (DW_AT_global_scope) to mark a data object > >>> that has a single location description with global scope might be cheaper > >>> than encoding it with a location list pointer and a default entry. > >> > >> Both DW_AT_external attribute and a hypothetical DW_AT_global_scope > >> attribute would describe scope, not the storage life of the object. > >> C unfortunately has confabulated the two concepts. > > > > In practice I believe DW_AT_external does both and I have used it that > > way to know whether to trust a single location description is globally > > valid. But yes, just like lifetime both "external" and "scope" are again > > bad words to use in this case and don't really express the thing we want > > (they might only accidentally). > > Section 3.3.1 describes the DW_AT_external with the following: > > If the name of the subroutine described by an entry with the tag > DW_TAG_subprogram is visible outside of its containing compilation > unit, that entry has a DW_AT_external attribute, which is a flag. > > Section 4.1 contains the following (describing an object): > > 2. A DW_AT_external attribute, which is a flag, if the name of a > variable is visible outside of its enclosing compilation unit. > > There is nothing about the lifetime of any object. Confabulating that > the scope attributes in DWARF imply something different is not supported > by the DWARF standard and will lead to misinterpretation of the DWARF > standard. > > > What about we call the flag attribute DW_AT_global_visible or > > DW_AT_global_location then it would be clear I think because it signals > > this isn't about language or DWARF tree (lexical) scoping? > > Symbol visibility is adequately described by the DW_AT_external attribute > as defined above. Object locations are adequately described by location > expressions and location lists.
I cannot tell whether we are in violent agreement or disagreement. Probably both :) I guess the confusion comes from some misunderstanding about assumptions of terminology used. As was said before the term lifetime as used in the description of location descriptors is confusing. Since DWARF doesn't talk about lifetime of objects anywhere else. What I seem to miss is how to express for a data object the address ranges where a a location description is valid for single location descriptions. I think it would really help if the use of "lifetime" in the definition of location descriptors was dropped and clarified by a definition based on valid address ranges. But maybe I am just misunderstanding something by reading too much or too little in this definition. I'll ask for a more specific example below so we don't have to argue about the specifics of words/definitions but can just agree on what a producer should emit for an consumer to know which ranges are valid. > >> Objects which have only a single location can be described with a location > >> expression. They don't need a location list with a default entry. > > > > For a data object that has a single location descriptor (DW_AT_location > > in exprloc class form), the valid range is given by the address ranges > > of the DIEs that own the data object. So it only lets me express the > > location in a restricted range. I do need to use a location list with > > (just) a default entry if I want to indicate that the location > > description has a valid global range. > > No, this interpretation is incorrect and is not supported by reading the > DWARF Standard. Please see Section 2.6. > > Perhaps you are confused by the following from Section 2.6 (which I think > is unambiguous): > > 1. Single location descriptions, which are a language independent > representation of addressing rules of arbitrary complexity built > from DWARF expressions and/or other DWARF operations specific to > describing locations. They are sufficient for describing the location > of any object as long as its lifetime is either static or the same as > the lexical block that owns it, and it does not move during its > lifetime. > > You seem to have interpreted "either/or" in the second sentence to mean "and". You are correct that I am confused about this definition. Not because of the either/or but about how to express the choices in DWARF. I don't understand how for a DWARF Data Object DIE I express whether a) its lifetime is static or b) the lifetime is the same as the lexical block that owns it. I assume that a "static lifetime" means the single location description of the Data Object DIE is valid for all address ranges. And I assume a "lifetime that is the same as the lexical block that owns it" means that the ranges for which the single location description is valid are the same as the ranges of the owning Program Scope DIE of the Data Object DIE. > > Is the above correct? Or is there another way to express that a location > > description is globally valid? Or am I misunderstanding the purpose of > > having a default entry in a location list? > > You do not need a location list for a static object. A simple location > expression will suffice. Could you give an example of how to express a static object in DWARF with a simple location description? And how does a consumer know the valid range of the simple location expression in that example is global and not the same as the lexical block that owns the Data Object DIE? > A default location list entry (as proposed in 130121.1) gives the location > of an object for address values which are not otherwise specified in the > location list. Maybe an example of this would be helpful too. I am under the (wrong) impression that a default location list entry would be used to describe "static objects". But the use case is probably different than I imagine. Thanks, Mark _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
