[Bug symtab/17547] over-eager debuginfo reading

["tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17547

--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Aaron Merey from comment #9)
> Related to this, I've been working on a patch to help address gdb's
> over-eager debuginfo downloading. The idea is to initially download a
> solib's .gdb_index section from debuginfod instead of its full debuginfo.
> Downloading full debuginfo is deferred until required.
> 
> https://sourceware.org/pipermail/gdb-patches/2022-November/193416.html

Sorry I haven't reviewed this yet.  I like this idea.

My current work for bug #29942 involves trying to move some gdb work
into the background, so that when many libraries must be read at
once, gdb isn't blocking while processing each one.

The corresponding idea with debuginfod would be to read the .gdb_index
remotely -- but not even wait for the download to complete before
setting up the "quick_symbol_functions" object.  Any code trying to
actually use the index would have to wait for the download to complete,
but this seems fine to me (assuming the user opts in, like in your patch).

Perhaps another thing that could be done here is to also trigger a
background download of the corresponding full files, so they are
more likely to be available when needed.

One funny thing here is that while I've been wanting gdb to move
towards the DWARF 5 index (see bug #24820), .gdb_index is
actually more self-contained -- the DWARF 5 index refers to
.debug_str, and gdb also needs .debug_aranges to work.  So, .gdb_index
is a little easier for this use.

However, .gdb_index also has issues, see bug #27930 (and I think there
may be others).

-- 
You are receiving this mail because:
You are on the CC list for the bug.