Hi Mark
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?
I don't think I expressed myself well:
Currently, a debugger that is able handle .dwp files is able to handle
resolving DWO IDs to that .dwp file.
The changes implement this for libdwfl, but they also make the specific
way of how libdw handles this the public API of debuginfod:
Resolving a DWO ID to a .dwp file. If we want a solution right now, this
is the only way because there is no such thing as a DWP id.
I think there is another way (which is theoretical at the moment), of
downloading the .dwp file from debuginfod and letting the debugger
handle the resolution of DWO IDs to the dwp (which might be via libdw,
but doesn't have to be).
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.
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?
I changed topics, before I was talking about a debugger, now I am
talking about build systems of the debugged software.
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.
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?
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.
Thanks,
Henning
