Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction

From: Wangnan (F)
Date: Thu Nov 19 2015 - 05:43:43 EST

On 2015/11/19 18:23, Ingo Molnar wrote:
* Wangnan (F) <wangnan0@xxxxxxxxxx> wrote:

On 2015/11/19 14:37, Ingo Molnar wrote:
* Wangnan (F) <wangnan0@xxxxxxxxxx> wrote:

perf cmdline is

# ./pref record -g -F 9 --call-graph dwarf ./test_dwarf_unwind

Use default events, precise_ip == 2 so uses PEBS.

Testetd 'cycles', 'cycles:p' and 'cycles:pp'. Only 'cycles:pp' captures
sample at callq. So maybe a PEBS problem?
Well, that's how our PEBS sampling works: we roll back the instruction pointer to
point at the instruction generating the sample. The state itself is
Just for curiosity:

how the interrupted process continue to execute, when the PC
saved in pt_regs still pointed to 'callq' but SP and stack has
already changes? Do we fix it in kernel, or by hardware?
PEBS is an asynchronous hardware tracing mechanism, when batched PEBS is used it
might not even result in any interruption of execution. The 'pt_regs' does not
necessarily correspond to an interrupted, restartable context - we take the RIP
from the PEBS machinery and also use LBR and disassembly to determine the previous
instruction, before reporting it to user-space.

You mean __intel_pmu_pebs_event(), which generates many perf_events?
Then their output are based on a same user stack, and could be error,
because the instruction has finished, and user stack could be modified.

Also, why not fixing rsp in kernel if that instruction is a 'callq'?
For avoiding instruction decoding?

Thank you.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at