Messages in this thread | | | Date | Fri, 1 Dec 2017 11:36:12 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 12/12] perf, tools, script: Implement dwarf resolving of instructions |
| |
On Mon, 27 Nov 2017 16:23:21 -0800 Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com> > > Implement resolving arguments of instructions to dwarf variable names. > > When we sample an instruction, decode the instruction and try to > symbolize the register or destination it is using. Also print the type. > It builds on the perf probe debugging information reverse lookup > infrastructure added earlier. > > The dwarf decoding magic is all done using Masami Hiramatsu's perf probe code. > > This is useful for > > - The PTWRITE instruction: when the compiler generates debugging information > for PTWRITE arguments. The value logged by PTWRITE is available to the > PT decoder, so it can print the value. > > - It also works for other samples with an IP, so it's possible to follow > their memory access patterns (but not the values) > > For the sample we use the instruction decoder to decode the instruction > at the sample point, and then map the arguments to dwarf information. > > For structure reference we only print the numeric offset, but do not > resolve the field name. > > Absolute memory references are not supported
Hmm, I think perf-probe also have same limitation.
> > It doesn't distinguish SSE (but AVX) registers from GPRs > (this would require extending the instruction decoder to detect SSE > instructions) > > Example: > > From perf itself > > % perf record -e intel_pt//u -a sleep 1 > % perf script --itrace=i0ns -F insnvar,insn,ip,sym -f 2>&1 | xed -F insn: -A -64 | less > ... > 4f7e61 xyarray__max_y pushq %rbp > 4f7e62 xyarray__max_y mov %rsp, %rbp > 4f7e65 xyarray__max_y sub $0x20, %rsp > 4f7e69 xyarray__max_y movq %rdi, -0x18(%rbp) { -24(xy), struct xyarray* } > 4f7e6d xyarray__max_y movq %fs:0x28, %rax > 4f7e76 xyarray__max_y movq %rax, -0x8(%rbp) { -8(xy), struct xyarray* } > 4f7e7a xyarray__max_y xor %eax, %eax > 4f7e7c xyarray__max_y movq -0x18(%rbp), %rax { -24(xy), struct xyarray* } > 4f7e80 xyarray__max_y movq 0x20(%rax), %rax > 4f7e84 xyarray__max_y movq -0x8(%rbp), %rdx { -8(xy), struct xyarray* } > 4f7e88 xyarray__max_y xorq %fs:0x28, %rdx > 4f7e91 xyarray__max_y jz 0x7 > 4f7e98 xyarray__max_y leaveq > 4f7e99 xyarray__max_y retq
Nice! :)
> > In this example we now know that this function accesses two fields in struct xyarray * > > Open Issues: > - It is fairly slow. Some caching would likely help.
OK, we can keep debuginfo open, but it may consume lot of memory.
> - Frame pointer references are usually not correctly resolved, > which are common in unoptimized code. That's usually fine > because memory access on the stack is not very interesting. > - It cannot resolve some references.
OK, let's find what kind of references can not be solved.
> > But I find it already quite useful. > > Signed-off-by: Andi Kleen <ak@linux.intel.com> [..] > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c > index 85fbeeb364bf..2a65ebed0998 100644 > --- a/tools/perf/util/probe-event.c > +++ b/tools/perf/util/probe-event.c > @@ -78,6 +78,9 @@ int init_probe_symbol_maps(bool user_only) > { > int ret; > > + if (host_machine) > + return 0;
What is this code for? Please put comment or make it separated patch.
Thanks!
> + > symbol_conf.sort_by_name = true; > symbol_conf.allow_aliases = true; > ret = symbol__init(NULL); > -- > 2.13.6 >
-- Masami Hiramatsu <mhiramat@kernel.org>
| |