Re: [Dwarf-Discuss] Best Practices wiki
On 03/28/14 06:37, Mark Wielaard wrote: Hi, Reading the DWARF5 proposal debug_aranges and address-less CUs http://dwarfstd.org/ShowIssue.php?issue=100430.2 I saw it said: "Rejected -- Recommend adding this as "best practice" on the wiki." I rather see this in the standard as non-normative text to be honest, but at least documenting this seems a good idea. I looked and found http://wiki.dwarfstd.org/index.php?title=Best_Practices but there this issue isn't mentioned yet. Could someone update it? The suggested text was: "If a compiler generates .debug_aranges sections, it should generate them for all compilation units, even when a compilation unit has no address ranges. This allows a consumer to distinguish between a compilation unit that has no ranges from a compilation unit generated by a compiler that does not generate .debug_aranges sections." The wiki has been updated. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Issue 100805.1 dynamic properties of types: reference interpretation
On 03/28/14 15:18, Cary Coutant wrote: The proposed DWARF5 suggestion "dynamic properties of types: reference interpretation" http://dwarfstd.org/ShowIssue.php?issue=100805.1 says: Accepted with modification -- Sept. 18, 2012 The second bullet in Section 2.19, pg. 40, reads as follows: - For a reference, the value is a reference to another entity which specifies the value of the attribute. Revised text: - For a reference, the value is a DWARF procedure that computes the attribute value". We did discuss this at the September meeting, but the issue page didn't get updated correctly. The revised text was supposed to be this: For a reference, the value is a reference to another DIE. This DIE may -- describe a variable which contains the attribute value -- describes a constant which is the attribute value -- contain a DWARF expression which computes the attribute value or is a dwarf procedure which computes the attribute value Issue 100805.1 has been updated to include this text. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
On 03/30/14 14:39, Mark Wielaard wrote: Hi, I was reading the DWARF5 proposal Issue 130121.1 Default Location List Entry http://dwarfstd.org/ShowIssue.php?issue=130121.1 and was wondering how to interpret the phrase "(provided that address is within the containing module)" from the introduction. In the actual text of the proposal there is no limit imposed on the default location list entry. It is just described as an unlimted number of address ranges, none of which overlap any of the addresss ranges defined earlier in the same location list. So I was wondering whether any limitation is implied or not. For example a Data Object DIE that has a DW_AT_location loclistptr that includes a default entry. Would the default entry address ranges of the default location list entry be constrained by the owning DIE of the Data Object (given by the DW_AT_low_pc and DW_AT_high_pc pair or DW_AT_ranges attribute in that owning DIE)? Or does the presence of the default entry imply that the location of the Data Object keeps valid even outside the owning DIE range (for example because it is a static C variable inside a function)? A default location list entry is a single location, as described in the proposal. It is not a list of address ranges. (Perhaps you mean that the location list is a sequence of non-overlapping address ranges?) The location list entries (including the default) are not constrained to be within the range of the containing DIE. The proposal creates a DWARF idiom, saying that a particular object can be found at all (valid) PC locations. A producer might instead create a default location list entry for a static object within a function which had the range of the function (i.e., the containing DIE), the compilation unit, or perhaps the entire executable. All of these would likely be reasonable descriptions of the object, from different points of view, although they might give different behaviors in a debugger. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
On Mon, 2014-03-31 at 08:39 -0700, Michael Eager wrote: > On 03/30/14 14:39, Mark Wielaard wrote: > > I was reading the DWARF5 proposal Issue 130121.1 Default Location List > > Entry http://dwarfstd.org/ShowIssue.php?issue=130121.1 and was wondering > > how to interpret the phrase "(provided that address is within the > > containing module)" from the introduction. > > > > In the actual text of the proposal there is no limit imposed on the > > default location list entry. It is just described as an unlimted number > > of address ranges, none of which overlap any of the addresss ranges > > defined earlier in the same location list. > > > > So I was wondering whether any limitation is implied or not. For example > > a Data Object DIE that has a DW_AT_location loclistptr that includes a > > default entry. Would the default entry address ranges of the default > > location list entry be constrained by the owning DIE of the Data Object > > (given by the DW_AT_low_pc and DW_AT_high_pc pair or DW_AT_ranges > > attribute in that owning DIE)? Or does the presence of the default entry > > imply that the location of the Data Object keeps valid even outside the > > owning DIE range (for example because it is a static C variable inside a > > function)? > > A default location list entry is a single location, as described in the > proposal. It is not a list of address ranges. (Perhaps you mean that > the location list is a sequence of non-overlapping address ranges?) Yes. > The location list entries (including the default) are not constrained to > be within the range of the containing DIE. OK, that makes some sense for normal location list entries. But it isn't immediately obvious for the default entry (IMHO). Better to be explicit about it if that is the case. > The proposal creates a DWARF idiom, saying that a particular object can > be found at all (valid) PC locations. OK. > A producer might instead create a > default location list entry for a static object within a function which > had the range of the function (i.e., the containing DIE), the compilation > unit, or perhaps the entire executable. All of these would likely be > reasonable descriptions of the object, from different points of view, > although they might give different behaviors in a debugger. So the new default location list entry expresses something that couldn't be expressed before? In that case not limiting the range of the default entry makes complete sense. I had assumed before that a Data Object with a single location expression DW_AT_location attribute (encoded using class exprloc) could be assumed either to have a lifetime of the lexical block that contained it, or that it would be static if declared as child of the top-level CU. My interpretation comes from 2.6 Location Descriptions, item 1. Single location descriptions which says "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." But another interpretation would be that the lifetime of a variable defined as child of a CU has as lifetime for its single location descriptor the range of the CU that contains it (assuming the CU is just another lexical block). I now think that my confusion is not with this new definition of a default entry. But with how to interpret the word "lifetime" in 2.6 Location Descriptions. When is that lifetime assumed to be static? Thanks, Mark ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] DW_LANG_C11
On Sun, 2014-03-30 at 21:06 +0200, Mark Wielaard wrote: > At first I didn't file an enhancement request since there are probably > no changes in how to interpret the meaning of DWARF attributes. But for > debuggers it is needed information to be able to correctly handle > expressions for the user related to the current CU since C11 did add > some keywords and so allows some expressions that are not valid in > earlier standards. I also filed a proposal to add a DW_AT_noreturn attribute for DW_TAG_subprogram to describe the new C11 (and available through an attribute in the GNU toolchain) noreturn function specifier: Subject: C11 _Noreturn function specifier attribute DW_AT_noreturn Name: Mark Wielaard Email: m...@redhat.com Section: 3.3.1 Page: 55 Type: Enhancement C11 introduces the new keyword _Noreturn that can be used as function specifier like inline. A function declared with a _Noreturn function specifier shall not return to its caller (it causes undefined behavior if it would). Similar functionality is available in the GNU Toolchain through the noreturn function attribute. It is sometimes useful for a debugger to know which functions can only be called, but shall never return. Figure 2. Attribute names Add DW_AT_noreturn Specifies a function that doesn't return to its caller. 3.3.1 General Subroutine and Entry Point Information Add a paragraph at the end saying: A subprogram entry may have a DW_AT_noreturn attribute, which is a flag. The attribute indicates whether the subroutine was declared with the "noreturn" keyword or property indicating that the function can be called, but will never return to its caller. Figure 20. Attribute encodings Add DW_AT_noreturn 0xXX flag. APPENDIX A ATTRIBUTES BY TAG VALUE Add DW_AT_noreturn to DW_TAG_subprogram. ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
On 03/31/14 10:59, Mark Wielaard wrote: My interpretation comes from 2.6 Location Descriptions, item 1. Single location descriptions which says "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." But another interpretation would be that the lifetime of a variable defined as child of a CU has as lifetime for its single location descriptor the range of the CU that contains it (assuming the CU is just another lexical block). I now think that my confusion is not with this new definition of a default entry. But with how to interpret the word "lifetime" in 2.6 Location Descriptions. When is that lifetime assumed to be static? Static means that the object is created when the program is instantiated, generally by being allocated a defined location by a linker and then loaded into memory. The lifetime of the object is from when the program is started to when it terminates, or as long as the memory space is extant. The use of the term lifetime may be a bit misleading in the DWARF context, since it implies that DWARF is describing dynamic behavior (at least, birth and death) when it only describes static characteristics of a program. The address ranges (whether low/high PC or location lists) specify the values of the PC where the associated information is valid. If the current PC (or the PC on the current call chain) is within the range, then the information is valid, otherwise it is (under certain circumstances) not. Your alternate interpretation may be equivalent under some circumstances, but not under others. For example, if you have a program with multiple CUs (most programs), each of which has static memory, there may be times during the program's execution when the current PC (or any call chain PC) does not fall within the low/high PC for a given CU. Still, if you stop the program with a debugger, the static data for for that CU is valid. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Add file attributes to debug-line file table (proposal 130701.1)
On Tue, 2014-03-18 at 08:32 -0700, Michael Eager wrote: > I'll pass your comments on to the DWARF Committee. Thanks. I also filed a comment for enhancement as proposal for DWARF5 now through http://dwarfstd.org/Comment.php to make sure the idea doesn't get lost (and since the deadline for new DWARF5 proposals is near). It probably needs some tweaking, but we can do that on the list if others are interested. Cheers, Mark ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Add file attributes to debug-line file table (proposal 130701.1)
FWIW I fully agree with this line of reasoning. I was going to propose it as well (though not as comperhensively) since we may decide that we want to use something other than "the low 64-bits of an md5 hash" to represent the file. Speaking of which, the particular hash and such should be explicitly changeable in the header. -eric On Tue, Mar 18, 2014 at 7:33 AM, Mark Wielaard wrote: > Hi, > > I was reading the suggestion for adding MD5 digests to the .debug_line > program header. http://dwarfstd.org/ShowIssue.php?issue=130701.1 > > Adding more attributes of files seems like a good thing, but as > specified this isn't extensible without changing the version number > again and defining new formats. Would it be possible to make this a > little more generic and vendor extensible? > > The .debug_macro proposal includes some language for defining > extensibility that could possibly be used. > http://dwarfstd.org/ShowIssue.php?issue=110722.1 > > So instead of a fixed file_entry_format (ubyte) field that just allows > one attribute (group) to be defined we could change it to something > like: > > file_attributes (ubyte) > - Possibly zero, number of attributes added to each file in the > file_names table. > file_attribute_description (sequence of attribute descriptions) > - Entries in this description describe which attributes and in what > format those attributes are encoded for each file entry. It has > file_attributes entries. Each entry consists of: > - file_attribute (ubyte). One of DW_LNF_timestamp, > DW_LNF_length, DW_LNF_MD5, ... > - file_attribute_format. A uleb128 describing the number of > arguments for the format followed a single byte describing the > form of the argument. The allowed values are DW_FORM_data1, > DW_FORM_data2, DW_FORM_data4, DW_FORM_data8, DW_FORM_sdata, > DW_FORM_udata, > DW_FORM_block, DW_FORM_block1, DW_FORM_block2, DW_FORM_block4, > DW_FORM_flag, > DW_FORM_string, DW_FORM_strp and DW_FORM_sec_offset. > > file_names (sequence of file entries) > - Each entry consists of the following values: > - A null-terminated string containing the full or relative path name > of a source file. > - An unsigned LEB128 number representing the directory index of a > directory in the include_directories section. > - For each file_attribute_format described in the > file_attribute_description entries the value encoded in the format > given by file_attribute_format. > > For example DW_LNF_timestamp and DW_LNF_length would have as format 1 > DW_FORM_udata. DW_LNF_MD5 could by described by 2 DW_FORM_data8. > > That would allow extending the number of attributes in later DWARF > versions or as vendor extensions and give consumers a way to skip over > any unknown attributes. > > Would something like the above suggestion be useful? Then I can work it > out a bit more. Did I miss any subtle corner cases? What is the status > of the .debug_macro proposal (110722.1)? It would be good to match the > descriptions of both extension mechanisms as much as possible. > > Thanks, > > Mark > > ___ > 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] Add file attributes to debug-line file table (proposal 130701.1)
As the original proposer, I say, Hear hear. The main reasons to choose that particular scheme were: - producers that use type sections must already have an MD5 implementation; - Visual Studio debugger integration uses it. But a more flexible scheme allowing other schemes would be a Good Thing. --paulr > -Original Message- > From: dwarf-discuss-boun...@lists.dwarfstd.org [mailto:dwarf-discuss- > boun...@lists.dwarfstd.org] On Behalf Of Eric Christopher > Sent: Monday, March 31, 2014 3:57 PM > To: Mark Wielaard > Cc: DWARF > Subject: Re: [Dwarf-Discuss] Add file attributes to debug-line file > table (proposal 130701.1) > > FWIW I fully agree with this line of reasoning. I was going to propose > it as well (though not as comperhensively) since we may decide that we > want to use something other than "the low 64-bits of an md5 hash" to > represent the file. Speaking of which, the particular hash and such > should be explicitly changeable in the header. > > -eric > > On Tue, Mar 18, 2014 at 7:33 AM, Mark Wielaard wrote: > > Hi, > > > > I was reading the suggestion for adding MD5 digests to the .debug_line > > program header. http://dwarfstd.org/ShowIssue.php?issue=130701.1 > > > > Adding more attributes of files seems like a good thing, but as > > specified this isn't extensible without changing the version number > > again and defining new formats. Would it be possible to make this a > > little more generic and vendor extensible? > > > > The .debug_macro proposal includes some language for defining > > extensibility that could possibly be used. > > http://dwarfstd.org/ShowIssue.php?issue=110722.1 > > > > So instead of a fixed file_entry_format (ubyte) field that just allows > > one attribute (group) to be defined we could change it to something > > like: > > > > file_attributes (ubyte) > > - Possibly zero, number of attributes added to each file in the > > file_names table. > > file_attribute_description (sequence of attribute descriptions) > > - Entries in this description describe which attributes and in what > > format those attributes are encoded for each file entry. It has > > file_attributes entries. Each entry consists of: > > - file_attribute (ubyte). One of DW_LNF_timestamp, > > DW_LNF_length, DW_LNF_MD5, ... > > - file_attribute_format. A uleb128 describing the number of > > arguments for the format followed a single byte describing the > > form of the argument. The allowed values are DW_FORM_data1, > > DW_FORM_data2, DW_FORM_data4, DW_FORM_data8, DW_FORM_sdata, > DW_FORM_udata, > > DW_FORM_block, DW_FORM_block1, DW_FORM_block2, DW_FORM_block4, > DW_FORM_flag, > > DW_FORM_string, DW_FORM_strp and DW_FORM_sec_offset. > > > > file_names (sequence of file entries) > > - Each entry consists of the following values: > > - A null-terminated string containing the full or relative path > name > > of a source file. > > - An unsigned LEB128 number representing the directory index of a > > directory in the include_directories section. > > - For each file_attribute_format described in the > > file_attribute_description entries the value encoded in the > format > > given by file_attribute_format. > > > > For example DW_LNF_timestamp and DW_LNF_length would have as format 1 > > DW_FORM_udata. DW_LNF_MD5 could by described by 2 DW_FORM_data8. > > > > That would allow extending the number of attributes in later DWARF > > versions or as vendor extensions and give consumers a way to skip over > > any unknown attributes. > > > > Would something like the above suggestion be useful? Then I can work > it > > out a bit more. Did I miss any subtle corner cases? What is the status > > of the .debug_macro proposal (110722.1)? It would be good to match the > > descriptions of both extension mechanisms as much as possible. > > > > Thanks, > > > > Mark > > > > ___ > > 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 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
