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.
Would've thought it'd be nice to integrate it with buildID and/or with debuginfod... On Fri, Jan 16, 2026 at 4:38 PM Mark Wielaard <[email protected]> wrote: > 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
