[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171201113612.9d7701cb43b3d2f7e6a637ce@kernel.org>
Date: Fri, 1 Dec 2017 11:36:12 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Andi Kleen <andi@...stfloor.org>
Cc: acme@...nel.org, jolsa@...nel.org, mhiramat@...nel.org,
adrian.hunter@...el.com, linux-kernel@...r.kernel.org,
Andi Kleen <ak@...ux.intel.com>
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@...stfloor.org> wrote:
> From: Andi Kleen <ak@...ux.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@...ux.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@...nel.org>
Powered by blists - more mailing lists