Re: parallel downloads of multiple debuginfo files

[Mark Wielaard <mark@klomp.org>]

Hi,

On Fri, 2022-04-08 at 17:31 -0400, Frank Ch. Eigler via Elfutils-devel
wrote:
> Hi -
> 
> > But once again - isn't this a problem that everyone using dwfl is
> > going to 
> > encounter? Should we not try to find a general solution to this
> > problem and 
> > fix it for all consumers of the API?
> 
> I suspect not many apps are going to have a complete list of files
> they know they'll need a priori.  A live profiler tends to find out
> about target files gradually.  A debugger uses debuginfo to help
> enumerate other debuginfo.  DWZ files can only be even known of when
> the base DWARF file is fetched.

A "two stage" profiler like perf, which first just records build-ids,
addresses and stack dumps, then afterwards does address/symbol/dwarf
resolution and backtracing, can know before the second stage all the
needed debuginfo for all the build-ids recorded. And a debugger can be
"greedy" and try to make sure all debuginfo for a core file or live
process is available up front. I believe gdb for example does try to
generate symbol tables for everything on startup in a background thread
so everything is available quickly once the user is really starting to
debug.

>   So yeah I'm not sure there exists a
> widespread general problem for which multithreading is not a workable
> solution.

That said, I am not sure multithreading is a real solution for the
above scenarios. Doing parallel downloads is often not that efficient.
It is better to reuse the same debuginfo_client handle to download
things serially, that way you can reuse the existing connection instead
of having to set it up for each download separately.

Cheers,

Mark