Hi Henning, On Fri, 2026-01-16 at 00:21 +0100, Henning Meyer wrote: > Almost all uses of the debuginfod servers are via the debuginfod client > library, but it is very simple to use the HTTP API directly, I wrote a > client of my own to allow tight integration with the async runtime I > use. I think it is worthwhile to keep the clear separation between what > is offered by the debuginfod API, the debuginfod client library and what > is offered by libdw. > > If I think about this in terms of API design, I would prefer an API that > would allow me to query the DWP directly from debuginfod.
Right. OK. Makes sense. So we should make sure to document the different API layers clearly. And when we get a way to query for a DWP directly (using some sort of DWP ID) then that would be preferable to (re)use DWO IDs to locate a DWP. > I don't think it is practical for people to share individual .dwo files, > they will create a and share .dwp archives, in the same way that we > share a static library instead of individual .o files. It is a lot > easier for the people maintaining the builds. But if the actual files > indexed and served are the .dwp files, then that should be reflected in > the URL schema of debuginfod and the client library should not have to > download multiple copies. > > I think if you add a /dwoid/ route now it might become deprecated or > fall out of use if it becomes possible to download the .dwp file directly. Let me think about that a bit. The issue of course is that we currently don't have a DWP ID. I think you are right that we should have a better way to resolve DWPs than just using the DWO ids to locate them. But that is currently all we have. And it seems there is a valid use case for (re)using DWO IDs to provide individual DWOs (and/or a whole DWP). The use case being you just build an executable with split-dwarf that you provide to some users to debug and pointing your debuginfod server at you build dir which contains all the .dwo files needed. > > 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? > > I know where the .dwp is since it built it myself and I tell the > debugger where to find it. > That approach obviously doesn't scale to the thousands of packages used > by a linux distribution. > > I really believe we should have a standardized hint for .dwp files. We certainly agree on that. I just sent a proposal to the DWARF committee: https://lists.dwarfstd.org/pipermail/dwarf-discuss/2026-January/002791.html It is a quick first draft, please feel free to comment and/or point out missing justification or mistakes in the proposal. Cheers, Mark
