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
