From: Namhyung Kim <namhyung@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Todd Lipcon <tlipcon@google.com>,
Stephane Eranian <eranian@google.com>,
"Mi, Dapeng1" <dapeng1.mi@intel.com>,
Ian Rogers <irogers@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-perf-users@vger.kernel.org
Subject: Re: perf script intel_pt decoding reading instructions from wrong shared lib
Date: Wed, 24 Jun 2026 13:23:11 -0700 [thread overview]
Message-ID: <ajw8r2Y2shs6sBJW@google.com> (raw)
In-Reply-To: <c45fea55-b03d-40ac-a89f-8882b057fe5b@intel.com>
Hello,
On Tue, Jun 02, 2026 at 10:32:02PM +0300, Adrian Hunter wrote:
> On 15/04/2025 00:59, Todd Lipcon wrote:
> > Hi folks,
> >
> > It seems there may be a bug in perf-script when processing intel_pt.
> > Specifically, in order to reconstruct the instructions, it maps
> > instruction pointers back to DSO-relative addresses, and then reads
> > from the associated ELF files to find the actual instructions that
> > were traced.
> >
> > In the case that the ELF file has an associated separate-debug ELF
> > file linked via `.gnu-debuglink` (common in some Linux distros), it
> > appears to be reading the debuginfo file instead of the shared library
> > that actually contains the code.
> >
> > I've posted a simple repro here:
> > https://github.com/toddlipcon/perf-debuglink-bug/blob/main/repro.sh
> >
> > I haven't dug into the code yet enough to see where it's going wrong,
> > but figured I would report to the users list first.
>
> Seems to be caused by commit 5363c306787c8 - see further below.
> Reverting that makes the issue go away.
Sorry for the trouble.
>
> With that commit, dso__load() sets the binary_type to the first symbol
> source file type, which is DSO_BINARY_TYPE__DEBUGLINK in this case.
> That causes dso__get_filename() to get the file name of the debug file,
> not the file actually executed.
>
> Leaving the binary_type as DSO_BINARY_TYPE__NOT_FOUND will result in
> try_to_open_dso() using either DSO_BINARY_TYPE__BUILD_ID_CACHE or
> DSO_BINARY_TYPE__SYSTEM_PATH_DSO.
Ok, I feel like we should split the dso access for the binary file (for
annotate or intel-pt) and debug symbols (symbol table or DWARF).
Probably we can use the binary_type and symtab_type respectively.
I'll take a look.
Thanks,
Namhyung
>
> A quick workaround hack:
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index dd30f17cb1ca..09fd79ca1d48 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1825,7 +1825,10 @@ int dso__load(struct dso *dso, struct map *map)
> if (next_slot) {
> ss_pos++;
>
> - if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND)
> + if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND ||
> + symtab_type == DSO_BINARY_TYPE__BUILD_ID_CACHE ||
> + (symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_DSO &&
> + dso__binary_type(dso) != DSO_BINARY_TYPE__BUILD_ID_CACHE))
> dso__set_binary_type(dso, symtab_type);
>
> if (syms_ss && runtime_ss)
prev parent reply other threads:[~2026-06-24 20:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 21:59 perf script intel_pt decoding reading instructions from wrong shared lib Todd Lipcon
2026-06-02 19:32 ` Adrian Hunter
2026-06-24 20:23 ` Namhyung Kim [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ajw8r2Y2shs6sBJW@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=dapeng1.mi@intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=tlipcon@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.