Hi Henning, On Mon, 2026-01-12 at 14:57 +0100, Henning Meyer wrote: > looking at this problem from the perspective of someone writing a > debugger with no elfutils dependency, > I don't understand why I would want /dwoid/ support in debuginfod at all.
Are you saying that as someone who doesn't use libelf and libdw, but does use an debuginfod-client? And if you have a debuginfod-client is it based on elfutils libdebuginfod or something else? > Debuginfod supplies missing files to debuggers, like stripped debug > information indexed by build ID. > I only want to use .dwo files for my local builds, I would not share > them with other people directly or via debuginfod. > > Instead I would share the .dwp. My debugger knows how to handle .dwp files. But your debugger doesn't know how to handle individual .dwo files? > Currently, .dwp files do not have an ID similar to a build ID, and it > looks like that is on oversight and there is a need for a DWP ID. > I don't think it is impossible to add generation of such a DWP ID to the > dwp tool or via another tool as a post-processing step. > > With such an ID, the executable can provide the DWP ID similar to the > build id or the "DWZ ID" (.gnu_debugaltlink). > Debuginfod clients can then request the .dwp by treating the ID as a > build ID. > > I know that this requires changing tools outside of elfutils, but it > seems a much cleaner design to me. Yes, it seems you are right, .alt/.multi files, or DWARF5 "Supplementary Object Files" (.sup), have a filename hint and a checksum/id to look them up. But for "DWARF Package Files" there is only this non-normative text: The package file is typically placed in the same directory as the application, and is given the same name with a “.dwp” extension. I think it makes sense to try to see if we can standardize on a .debug_dwp section that provides similar hints like .gnu_debugaltlink or .debug_sup. But since we don't have that currently, how does your debugger handle resolving .dwp files? > If we want debuginfod to handle .dwo files, then we need a design > similar to what Pablo proposed, but I think the DWP case is more > important for debuginfod than the DWO case and the DWP case should not > necessarily be implemented in terms of the DWO case. > > Am I missing something? I don't think you are missing something, but we are missing a clearly defined process of resolving dwp files. And currently for split dwarf we just have DWO ids to resolve. So it makes sense IMHO to have debuginfod provide a way to resolve the DWO ids since that is all we currently have. And Pablo's design makes it so we can resolve such IDs with either individual .dwo files or a full .dwp. > From a purely practical standpoint, a DWP file may be gigabytes in size > and contain thousands of DWO ids, and debuginfod_client will keep lots > of redundant copies with the proposed approach. > I don't like that, I also think debuginfod_client should not try to > deduplicate on its own. I don't know how to resolve that in the proposed > design. Thanks for your feedback. I have to think a bit more about this. > Thanks for working on this, Pablo. I would like to see broader adoption > of both debuginfod and -gsplit-dwarf and there is clearly a gap in the > tooling. Yes, thanks to you both for your insights/code. Cheers, Mark
