<div dir="ltr">Fair enough - thanks for the context. I haven't seen _sup used/not familiar with its finer points. Consistency doesn't seem so bad, even if it's with what seems like a fairly underused/old feature so maybe the design could be revisited.<br><br>Would've thought it'd be nice to integrate it with buildID and/or with debuginfod...</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 16, 2026 at 4:38 PM Mark Wielaard <<a href="mailto:mark@klomp.org">mark@klomp.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David,<br>
<br>
On Fri, Jan 16, 2026 at 01:09:46PM -0800, David Blaikie wrote:<br>
> On Fri, Jan 16, 2026 at 11:20 AM Mark Wielaard via Dwarf-discuss <<br>
> <a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br>
> <br>
> > # 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>
> ><br>
> <br>
> I appreciate the general idea, though have some reservations I guess.<br>
> <br>
> There are already existing tools like GNU build-id (<br>
> <a href="https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id" rel="noreferrer" target="_blank">https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id</a><br>
> ) - is that applicable here (put a build id in the dwp to match the<br>
> executable)? Are there tradeoffs/is this a matter of wanting to standardize<br>
> this sort of existing practice?<br>
<br>
build-ids are a (non-standardized) ELF concept. So that is why I<br>
didn't immediately think of using that. And as far as I know there is<br>
no existing practice of mapping the .dwp file except finding it by<br>
name. But now that you mention it, it could work, but would be a bit<br>
limiting because it can only be used for a one-to-one relationship<br>
between files. In theory a DWARF Package file could contain the dwo<br>
sections for multiple object files (which would have different<br>
build-ids).<br>
<br>
In general I think it would be good to have a standardized mechanism<br>
that matches existing DWARF standards like the similar .debug_sup for<br>
Supplemental DWARF files that this proposal is based on.<br>
<br>
> If the identifier were specified as a specific hash of the DWP file - then<br>
> maybe the DWP file wouldn't need to contain the hash/be updated/modified<br>
> once created? (though if the identifier is arbitrary, perhaps that's not<br>
> necessary either - assuming the producer can produce the identifier before<br>
> producing the executable or the DWP file (a hash of their inputs) - then<br>
> both can be stamped during their creation rather than as a fixup<br>
> afterwards, though it puts more cost on the producer to have that extra<br>
> external data, etc)<br>
<br>
I am not sure I am following. I think the expectation is that the<br>
ID/checksum would be a global unique identifier, probably as a hash<br>
over the relevant .debug_* sections that are added to it during<br>
creation. But like the .debug_sup checksum/id the specific way how the<br>
id is created isn't specified. What matters is that the object file<br>
containing the .debug_dwp checksum/id matches the target checksum/id<br>
in the DWARF Package file that contains all the dwo sections for the<br>
skeleton DIEs.<br>
<br>
> Is the `is_package` field necessary - it seems like, while it'd require<br>
> context-sensitivity (the consumer would have to know if it's parsing the<br>
> DWP or the executable), it wouldn't be overly burdensome to infer the<br>
> "is_package" property from the context/where the section appears?<br>
<br>
I guess it could also be derived from the fact that the filename is<br>
empty. But it is just one byte which could be used as sanity check and<br>
it matches is_supplemental in .debug_sup.<br>
<br>
Cheers,<br>
<br>
Mark<br>
</blockquote></div>