Hi everyone,
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.
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.
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.
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?
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 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.
Regards,
Henning
