Re: [PATCH v4 2/5] perf dso: Allow reading DSO data from an explicit file

[Alireza Haghdoost]

On Fri, Oct 2, 2026 at 3:13 PM Ian Rogers <irogers@xxxxxxxxxx> wrote:
>
> On Fri, Oct 2, 2026 at 11:46 AM Alireza Haghdoost via B4 Relay
> <devnull+haghdoost.uber.com@xxxxxxxxxx> wrote:
> >
> > From: Alireza Haghdoost <haghdoost@xxxxxxxx>
> >
> > The DSO data cache derives the file to open from the DSO's binary type,
> > which can resolve to the runtime image rather than the file a symbol
> > table was read from. The lazy symbol loader added later in this series
> > reads symbol names at string-table offsets in the file the symbol table
> > came from. With split debuginfo, the data cache would apply those
> > debuginfo offsets to the runtime image.
> >
> > This patch adds dso__data_set_path() so a DSO can be configured to read
> > from one exact file while keeping the data cache's descriptor eviction
> > and reopening. The path is used only when the data cache opens the file;
> > dso__get_filename() and its debuginfo callers are unchanged. Such DSOs
> > may be owned privately rather than being part of a dsos collection, so
> > the patch also drops the assertion that every opened data DSO is in one.
>
> I think some context is missing here. Why do I want a DSO that isn't
> part of a machine's DSOs? I can see a use for testing, do you want
> this feature for more than testing?
>

Yes, the production consumer is 4/5 in
tools/perf/util/symbol-elf.c:2143-2146, where
dso__build_ondemand_index() creates the private data DSO and sets the exact
symbol-source path.

The lazy loader needs this data-cache handle because the symbol table may
come from separate debuginfo rather than the runtime image. Namhyung asked
during the v2 review that this known split-debuginfo problem be separated
from the lazy loader as an independent fix.

Thanks,
Alireza