All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.