lkml.org 
[lkml]   [2017]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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>

\
 
 \ /
  Last update: 2017-12-01 08:43    [W:0.119 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site