<div dir="ltr"><div dir="ltr">On Fri, Jan 16, 2026 at 11:20 AM Mark Wielaard via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>> wrote:</div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># DWARF Package file (.dwp) .debug_dwp ID<br>
<br>
## Background<br>
<br>
Unlike DWARF Supplementary Object Files DWARF Package files don't have<br>
an ID or checksum to look them up or match them. There is only a non-<br>
normative hint that the package file is typically placed in the same<br>
directory as the application, and is given the same name with a ".dwp"<br>
extension. This makes storing the package files somewhere else or<br>
requesting them from a "debug server" inconvenient.<br></blockquote><div><br>I appreciate the general idea, though have some reservations I guess.<br><br>There are already existing tools like GNU build-id ( <a href="https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id">https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id</a> ) - is that applicable here (put a build id in the dwp to match the executable)? Are there tradeoffs/is this a matter of wanting to standardize this sort of existing practice?<br><br>If the identifier were specified as a specific hash of the DWP file - then maybe the DWP file wouldn't need to contain the hash/be updated/modified once created? (though if the identifier is arbitrary, perhaps that's not necessary either - assuming the producer can produce the identifier before producing the executable or the DWP file (a hash of their inputs) - then both can be stamped during their creation rather than as a fixup afterwards, though it puts more cost on the producer to have that extra external data, etc)<br><br>Is the `is_package` field necessary - it seems like, while it'd require context-sensitivity (the consumer would have to know if it's parsing the DWP or the executable), it wouldn't be overly burdensome to infer the "is_package" property from the context/where the section appears?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">## Overview<br>
<br>
We propose to add an identifier, a .debug_dwp section, that contains a<br>
filename and checksum to match up application or shared library object<br>
files with skeleton units to a dwp file created for all the dwo<br>
sections. This is similar to how supplemental files can be identified.<br>
<br>
## Proposed Changes<br>
<br>
In 7.3.5 DWARF Package Files add the following to the end of the second<br>
paragraph (informational):<br>
<br>
"The package file also contains a .debug_dwp section with a unique DWP<br>
ID."<br>
<br>
Add a new section "7.3.5.4 Format of the .debug_dwp Section" (based on<br>
a similar description of the .debug_sup section in "7.3.6 DWARF<br>
Supplementary Object Files"<br>
<br>
```<br>
Both the DWARF package file and the original application object file<br>
containing the skeleton units contain a .debug_dwp section that<br>
establishes the relationship between the object file containing the<br>
skeleton units and the DWARF package file containing the dwo units.<br>
<br>
The .debug_dwp section contains:<br>
<br>
1. version (uhalf)<br>
A 2-byte unsigned integer representing the version of the DWARF<br>
information for the DWARF package file.<br>
<br>
The value in this field is 6.<br>
<br>
2. is_package (ubyte)<br>
A 1-byte unsigned integer, which contains the value 1 if it is<br>
in the DWARF package file that other executable or shared object files<br>
refer to, or 0 if it is an executable or shared object with skeleton<br>
units referring to a DWARF package file.<br>
<br>
3. dwp_filename (null terminated filename string)<br>
If is_package is 0, this contains either an absolute filename for the<br>
DWARF package file, or a filename relative to the object file<br>
containing the .debug_dwp section. If is_package is 1, then<br>
dwp_filename is not needed and must be an empty string (a single null<br>
byte).<br>
<br>
4. dwp_checksum_len (unsigned LEB128)<br>
Length of the following dwp_checksum field;<br>
this value can be 0 if no checksum is provided.<br>
<br>
5. dwp_checksum (array of ubyte)<br>
An implementation-defined integer constant value that<br>
provides unique identification of the package file.<br>
```<br>
<br>
In Appendix F.3 DWARF Package File Example<br>
<br>
Change "plus two" to "plus three" in the second paragraph:<br>
<br>
"The package file contains the same set of sections as a split DWARF<br>
object file, plus two additional sections described below."<br>
<br>
to<br>
<br>
"The package file contains the same set of sections as a split DWARF<br>
object file, plus three additional sections described below."<br>
<br>
Add a line to Figure F.9: Sections and contributions in example package<br>
file demo.dwp:<br>
<br>
".debug_dwp" | "DWP ID generated by package utility"<br>
<br>
At the end of the text of Appendix F.3 add the following paragraph:<br>
<br>
Add a new Figure F.12 "Example DWP ID section"<br>
<br>
... figure to be provided based on new 7.3.5.4 Format of the .debug_dwp<br>
Section ...<br>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div></div>
</div>