Re: [PATCH 12/12] perf, tools, script: Implement dwarf resolving of instructions

[Masami Hiramatsu]

On Mon, 27 Nov 2017 16:23:21 -0800
Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx>
[..]
> 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@xxxxxxxxxx>