|
DWARF Standard
|
171216.1 |
Aleksandr Povaliaev |
Extend DW_TAG_compile_unit entry with DW_TAG_hash_value |
Enhancement |
Rejected |
Jini Susan George |
Section 3.1.1, pg 66
Hi all,
here is my proposal to extend DW_TAG_compile_unit entry with a set of attributes.
Actually one attribute is mostly needed, namely DW_TAG_hash_value. This attribute
is presumed to be optional. If a compile unit (DW_TAG_compile_unit) has got
this attribute (DW_TAG_hash_value), the attibute value is generated as a hash
function taken over all the compile unit DWARF debug information. Hash
function might be selected as SHA1.
The following changes to DWARF5 standard document are proposed in details:
1) Add to "3.1.1 Full and Partial Compilation Unit Entries" section, the
description of new "DW_TAG_hash_value" attribute. It is going to be
something like (on page 66): "17. A DW_TAG_hash_value attribute whose
value is 20 bytes SHA1 hash function (see, RFC 3174) taken over all
the current compile unit DWARF debug information items. It means that
if any of the current compile unit item is changes (either its attributes
or any attribute value) the value of DW_TAG_hash_value attribute will be
changed respectfully."
2) Add to "2.2 Attribute Types" section the description of
"DW_TAG_hash_value" attribute: "Hash value of CU debug data".
3) Add to "7.5.4 Attribute Encodings" section,
Attribute name | Value | Classes
-------------------------------------------------------------
DW_TAG_hash_value | 0x8d | block
4) Add to "Appendix F. Split DWARF Object Files (Informative)" section
the appropriate information:
| Unit Kind
Attribute | Conventional | Skeleton and Split
| Full & Type | Skeleton Split Fill Split Type
| Partial |
------------------------------------------------------------------------------------------------
DW_TAG_hash_value | X | X
Rationale:
The main idea behind introducing "DW_TAG_hash_value" attribute for a
compilation unit (CU) is to reduce the time which is required by DWARF
information parsers. And if a particular CU has been previously parsed by
debugger (or it might be some other application), every next run the debugger
might just check either "DW_TAG_hash_value" attribute value is changed.
Whenever the attribute value is not changed (i.e. SHA1 hash is the same),
it means that all the previous results from parsing CU DWARF data might
be used again and re-parsing is not necessary. Here, different application
might use caching techniques to make work with large DWARF debug data more
efficient.
--
2021-10-04: Rejected. Additional implementation experience or proof-of
concept is needed.