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 <m...@redhat.com> 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
