Hi Mark,
Thanks for the detailed review! Very excited to do my first patch :)
Answers inline below.
> I believe. So the corresponding support in GDB would be to use the
> debuginfod-client interface to fetch it?
Yes, but GDB would need explicit changes. GDB has its own DWARF reader
(gdb/dwarf2/read.c) and debuginfod integration (gdb/debuginfod-support.c)
GDB would need to:
1. Add debuginfod_dwo_query() to debuginfod-support.c calling the new
debuginfod_find_dwo() API
2. Modify open_dwo_file() in dwarf2/read.c to call it when local search
fails (similar to how debuginfod_debuginfo_query works for debug info)
> Do you support single-file split-dwarf? Where the split DWARF is in the
> .o file together with the skeleton sections?
Yes. The scanner looks for DW_UT_split_compile/DW_UT_split_type units
regardless of file extension. The schema tracks this (is_dwp = 0 for
.dwo or .o files).
> What if there are both separate .dwo files and a .dwp containing the
> same ID? Is one preferred over the other?
Currently ordered by mtime desc, so most recent wins. We could add
explicit preference (e.g., prefer .dwo over .dwp) if desired.
> How does the caching work? When you get a dwp file do you create
> symlinks for all dwoids in it under ~/.cache/debuginfod_client/?
> Or is libdw supposed to register/cache them?
Cache path is ~/.cache/debuginfod_client/dwoid/{id}/debuginfo. No
symlinks - the whole file is cached under the requested ID. If two
IDs from the same .dwp are requested, it's cached twice. Simpler than
scanning the .dwp to create symlinks, and libdw handles .dwp parsing
anyway.
> I would have to see the code to really understand how that works.
> [re: dwarf_set_dwo_lookup and libdwfl integration]
Should be clear from the patches. The callback receives the 64-bit
DWO ID and returns a file descriptor (or -1). Thread-safe via
dwarf_lock mutex.
> I think I don't fully understand the resolving part when the dwo isn't
> available locally.
Also should be clear from the patches - __libdw_find_split_unit()
tries local paths first, then invokes the callback if registered.
> We also just added a workflow that goes through forge.sourceware.org.
> But nobody has used that yet. If you like you could be our first
> contributor that uses that. If you register at
> https://forge.sourceware.org/user/sign_up I can add you to the
> Contributors group of https://forge.sourceware.org/elfutils/elfutils so
> you can create a fork and merge request. Do note that this is new to
> all of us so expect some learning required on both ends. But we are
> happy to learn!
Alright, I am happy to spearhead this workflow :) I created an account as
instructed here: https://forge.sourceware.org/pablogsal
Let me know when things are ready and I can give the fork a go!
Thanks,
Pablo
