From: Namhyung Kim <namhyung@kernel.org>
To: Gennady Kupava <gennady.kupava@gmail.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [DISCUSSION] Three problems behind broken "perf --call-graph dwarf" on AMD: IP and stack dump mismatch, libdw fails on lld's layout, and the unwinder fallback never runs
Date: Fri, 28 Aug 2026 09:47:05 -0700 [thread overview]
Message-ID: <apG7ifoxTzqJIjix@google.com> (raw)
In-Reply-To: <apCyQ93c48Dy4H-S@google.com>
On Thu, Aug 27, 2026 at 02:55:15PM -0700, Namhyung Kim wrote:
> Hello,
>
> Thanks a lot for your detailed report! It's good but let me jump into
> the action items directly.
>
> On Fri, Aug 21, 2026 at 10:49:59PM +0100, Gennady Kupava wrote:
> [SNIP]
> > Suggestions and questions
> > =========================
> >
> > 1. Kernel: the fix that was applied to the kernel-side call chain -
> > passing iregs rather than the modified regs - looks like it applies
> > verbatim to PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER. Should
> > those be derived from iregs too when the event requests a user stack
> > dump? If the precise IP is worth keeping in the sample regardless,
> > should such samples carry a flag, so that userspace knows the IP and the
> > stack do not belong together? Today nothing distinguishes them.
>
> As Ravi said, you can check the misc field if the IP is from precise
> events.
>
> And there's PERF_SAMPLE_REGS_INTR which I believe captures registers
> from the interrupt handler. I don't remember why we have both REGS_USER
> and REGS_INTR but it seems REGS_INTR would work for callchains.
Of course, it won't work when the interrupt was in kernel mode. :(
Thanks,
Namhyung
next prev parent reply other threads:[~2026-08-28 16:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 21:49 [DISCUSSION] Three problems behind broken "perf --call-graph dwarf" on AMD: IP and stack dump mismatch, libdw fails on lld's layout, and the unwinder fallback never runs Gennady Kupava
2026-08-24 13:35 ` Ravi Bangoria
2026-08-25 18:05 ` Ian Rogers
2026-08-27 21:55 ` Namhyung Kim
2026-08-28 16:47 ` Namhyung Kim [this message]
2026-08-28 16:58 ` Namhyung Kim
2026-08-31 5:05 ` Ravi Bangoria
2026-09-01 15:19 ` Namhyung Kim
2026-09-03 8:39 ` Mi, Dapeng
2026-09-03 11:36 ` Ravi Bangoria
2026-09-03 11:59 ` Mi, Dapeng
2026-09-03 16:02 ` Ravi Bangoria
2026-09-04 0:22 ` Mi, Dapeng
2026-09-05 10:14 ` Gennady Kupava
2026-09-07 6:23 ` Mi, Dapeng
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=apG7ifoxTzqJIjix@google.com \
--to=namhyung@kernel.org \
--cc=gennady.kupava@gmail.com \
--cc=linux-perf-users@vger.kernel.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 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.