Hi David, On Fri, Jan 16, 2026 at 01:09:46PM -0800, David Blaikie wrote: > On Fri, Jan 16, 2026 at 11:20 AM Mark Wielaard via Dwarf-discuss < > [email protected]> wrote: > > > # DWARF Package file (.dwp) .debug_dwp ID > > > > ## Background > > > > Unlike DWARF Supplementary Object Files DWARF Package files don't have > > an ID or checksum to look them up or match them. There is only a non- > > normative hint that the package file is typically placed in the same > > directory as the application, and is given the same name with a ".dwp" > > extension. This makes storing the package files somewhere else or > > requesting them from a "debug server" inconvenient. > > > > I appreciate the general idea, though have some reservations I guess. > > There are already existing tools like GNU build-id ( > https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id > ) - 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?
build-ids are a (non-standardized) ELF concept. So that is why I didn't immediately think of using that. And as far as I know there is no existing practice of mapping the .dwp file except finding it by name. But now that you mention it, it could work, but would be a bit limiting because it can only be used for a one-to-one relationship between files. In theory a DWARF Package file could contain the dwo sections for multiple object files (which would have different build-ids). In general I think it would be good to have a standardized mechanism that matches existing DWARF standards like the similar .debug_sup for Supplemental DWARF files that this proposal is based on. > 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) I am not sure I am following. I think the expectation is that the ID/checksum would be a global unique identifier, probably as a hash over the relevant .debug_* sections that are added to it during creation. But like the .debug_sup checksum/id the specific way how the id is created isn't specified. What matters is that the object file containing the .debug_dwp checksum/id matches the target checksum/id in the DWARF Package file that contains all the dwo sections for the skeleton DIEs. > 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? I guess it could also be derived from the fact that the filename is empty. But it is just one byte which could be used as sanity check and it matches is_supplemental in .debug_sup. Cheers, Mark -- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
