From: Tudor-Stefan Magirescu <tudor.magirescu@gmail.com>
To: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
irogers@google.com, adrian.hunter@intel.com
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
tudor.magirescu@gmail.com
Subject: [RFC PATCH v2 0/1] perf scripts flamegraph: Add --asm option
Date: Thu, 27 Aug 2026 17:23:53 +0200 [thread overview]
Message-ID: <20260827152354.1513813-1-tudor.magirescu@gmail.com> (raw)
In-Reply-To: <20260821090555.1B6DC1F000E9@smtp.kernel.org>
Flame graphs report samples at function granularity, so a wide frame shows
which function is hot but not which part of it. Obtaining that requires
perf annotate, which reports per-instruction counts without the calling
context of a flame graph. This adds an --asm option that appends the
sampled instruction as a leaf node, so both views are available at once.
While testing locally on x86_64 I noticed that when recording using
--call-graph fp and :p event modifiers, the top stack frame of the
callchain and the sample information don't agree. In my case, it appears
that the callchain's ip is exactly one instruction after the sample's ip.
perf annotate seems to ignore the callchain information and only uses the
sample ip to record the distributions, which I replicated in the script,
so that both tools attribute a sample to the same instruction.
This approach has 2 problems:
1) (Occurs only when recording with --call-graph fp and :p) The sample and
top of callchain might not refer to the same function, which means that
some instructions might be misattributed to a wrong call stack. Is a fixup
wanted here, and if so should it live in this script or where the
callchain is built?
2) A binary object might contain 2 or more symbols with the same name but
different code (e.g., when defining 2 static functions with the same name
in different translation units). In this case, the approach cannot
disambiguate between them, so instructions might get misattributed. Would
exporting the symbol start and end for the sample, as already present for
callchain entries, be acceptable? This would also remove the objdump -t
call entirely.
Changes since V1:
- Warn to stderr and disable annotations if objdump is not found at startup.
- Resolve DSOs through perf's build-id cache rather than raw DSO path.
- Try debug before elf in the build-id cache to support stripped binaries.
Tudor-Stefan Magirescu (1):
perf scripts flamegraph: Add --asm option
tools/perf/scripts/python/flamegraph.py | 161 ++++++++++++++++++++++++
1 file changed, 161 insertions(+)
--
2.43.0
next prev parent reply other threads:[~2026-08-27 15:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 8:50 [RFC PATCH 0/1] perf scripts flamegraph: Add --asm option Tudor-Stefan Magirescu
2026-08-21 8:50 ` [RFC PATCH 1/1] " Tudor-Stefan Magirescu
2026-08-21 9:05 ` sashiko-bot
2026-08-27 15:23 ` Tudor-Stefan Magirescu [this message]
2026-08-27 15:23 ` [RFC PATCH v2 " Tudor-Stefan Magirescu
2026-08-27 15:37 ` sashiko-bot
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=20260827152354.1513813-1-tudor.magirescu@gmail.com \
--to=tudor.magirescu@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox