Re: [PATCH 01/15] perf debuginfo: Fetch debuginfo keyed by build ID using debuginfod

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Thu, Sep 17, 2026 at 10:58:15AM -0700, Ian Rogers wrote:
> On Thu, Sep 17, 2026 at 8:55 AM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> 
> [snip]
> 
> > +/*
> > + * The build IDs already fetched in this session, and the path of the file
> > + * that came back for each, so that the repeated requests for the same build
> > + * ID, dso__debuginfo() is called per symbol annotated, are answered with a
> > + * strdup() instead of another client: the file is in the debuginfod client
> > + * cache already and its path checked before being handed out, in case that
> > + * cache is cleaned from under us.
> > + *
> > + * Guarded by debuginfod__fetch_lock.  Only a fetch that brought a file back
> > + * gets an entry: one that didn't is recorded in debuginfod__misses as a miss,
> > + * and that is what keeps the rest of the session from asking for it again.
> > + * Like debuginfod__misses this grows with the number of build IDs in the
> > + * workload, one small entry each, and is not trimmed.
> > + */
> > +struct debuginfo_lookup {
> > +       struct list_head         node;
> > +       struct build_id          bid;
> > +       char                    *path;
> > +};
> > +
> > +static LIST_HEAD(debuginfo_lookups);
> 
> I'd still prefer keeping the debuginfos owned by the DSOs rather than
> having debuginfo use a global cache of debuginfos - I expect the
> debuginfos to have some non-trivial memory overhead. With the
> debuginfo in the DSO, when/if the DSO goes away we can reclaim all the
> memory without worrying about a separate global data structure. We can
> find DSOs in multiple ways with dsos__findnew_id:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/dsos.c#n343
> We match by name, but if those differ:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/dsos.c#n117
> We match by inode and/or build ID:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/dso.c#n1473
> 
> So struct dsos is a build ID indexed store of DSOs and their owned
> debuginfo. We find DSOs off a machine, but I believe we always have
> access to the relevant struct machine. In the worst case for probes,
> for example, we need to set up a host machine. Using machines
> inherently provides some lock sharding, and they also have the ability
> to reclaim memory.

Working on it, no preference, so doing it the way you describe seems ok,
will post later.

- Arnaldo