[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181109005423.GZ6218@tassilo.jf.intel.com>
Date: Thu, 8 Nov 2018 16:54:23 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Milian Wolff <milian.wolff@...b.com>
Cc: Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
Jiri Olsa <jolsa@...nel.org>, namhyung@...nel.org,
linux-perf-users@...r.kernel.org,
Arnaldo Carvalho <acme@...nel.org>
Subject: Re: PEBS level 2/3 breaks dwarf unwinding! [WAS: Re: Broken dwarf
unwinding - wrong stack pointer register value?]
> - Independently, when I add a custom printk manually in `arch/x86/events/
> intel/ds.c` at the end of `setup_pebs_sample_data`, then I'm never seeing any
> differences between SP in iregs/pebs/regs. Shouldn't it also be recorded via
> PEBS? Or is it just chance that I'm never seeing any difference in
> setup_pebs_sample_data between iregs->sp and regs->sp?
It will depend on the workload.
>
> - Generally, how do we want to handle this bug? If `--intr-regs` would
> actually record a different IP than stored in uregs in the perf.data file,
> then we could use that as a fallback for unwinding, when it fails the first
> time. Or should we always unwind from that IP? How do we mark the "actual"
> frame/IP then, if that differs?
I don't think the regs include IP currently? Would need to add it.
Then could report everything from the original stack in intr-regs,
and this would address that problem.
Yes it might be useful to add some indication to the sample that
there is a potential divergence between the backtrace and the IP.
Would also need to report that in perf report then.
-Andi
Powered by blists - more mailing lists