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

[Ian Rogers]

On Thu, Sep 17, 2026 at 8:55 AM Arnaldo Carvalho de Melo
<acme@xxxxxxxxxx> 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.

Thanks,
Ian