lkml.org 
[lkml]   [2018]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PEBS level 2/3 breaks dwarf unwinding! [WAS: Re: Broken dwarf unwinding - wrong stack pointer register value?]
Date
On Dienstag, 6. November 2018 21:24:11 CET Andi Kleen wrote:
> > Where would I look for the source to change here? So far, I only
> > concentrated on the userspace side of perf in tools/perf.
>
> Kind of similar to
>
> a405bad5ad20 perf/x86: Add Haswell specific transaction flag reporting
> fdfbbd07e91f perf: Add generic transaction flags
>
> Report the original (not overwritten) regs->ip and regs->sp

Thanks a lot Andi! With your help, I have managed to find the exact issue for
my scenario. Turns out, it really is "just" the instruction pointer that is
wrong. I.e. originally we have IP = 0x7feda32ca68c, but with PEBS we correct
that to IP = 7feda32ca688. The SP register value stays the same according to
my printk output. Using the original IP value, we can unwind correctly since
we point to the correct place in the .eh_frame section. The PEBS IP points to
a different position in the .eh_frame section, which is "too early".

That brings up some questions:

- I noticed `perf record --intr-regs`, but the values recorded in the
perf.data file are always the same. I.e. comparing uregs and iregs, I always
see the same values printed by `perf script`. This smells like a bug to me,
but so far I haven't figured out why this happens...

- 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?

- 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?

Thanks

--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2018-11-07 23:42    [W:0.075 / U:1.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site