Messages in this thread | | | Date | Thu, 19 Nov 2015 18:43:14 +0800 | From | "Wangnan (F)" <> | Subject | Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction |
| |
On 2015/11/19 18:23, Ingo Molnar wrote: > * Wangnan (F) <wangnan0@huawei.com> wrote: > >> >> On 2015/11/19 14:37, Ingo Molnar wrote: >>> * Wangnan (F) <wangnan0@huawei.com> 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 >>> post-instruction. >> 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. Right?
Also, why not fixing rsp in kernel if that instruction is a 'callq'? For avoiding instruction decoding?
Thank you.
| |