<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/tools/perf/util/Build, branch v4.9.16</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>perf jit: Enable jitdump support without dwarf</title>
<updated>2017-01-26T07:24:36+00:00</updated>
<author>
<name>Maciej Debski</name>
<email>maciejd@google.com</email>
</author>
<published>2016-10-13T10:59:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=03f5be20ec9befe477e9978bdba2b1f4f2ca9e42'/>
<id>03f5be20ec9befe477e9978bdba2b1f4f2ca9e42</id>
<content type='text'>
commit 621cb4e7837e39d25a5af5a785ad282cdd2b4ce8 upstream.

This patch modifies the build dependencies on the jitdump support in
perf. As it stands jitdump was wrongfully made dependent 100% on using
DWARF. However, the dwarf dependency, only exist if generating the
source line table in genelf_debug.c. The rest of the support does not
need DWARF.

This patch removes the dependency on DWARF for the entire jitdump
support. It keeps it only for the genelf_debug.c support.

Signed-off-by: Maciej Debski &lt;maciejd@google.com&gt;
Reviewed-by: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Anton Blanchard &lt;anton@ozlabs.org&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/1476356383-30100-3-git-send-email-eranian@google.com
Fixes: e12b202f8fb9 ("perf jitdump: Build only on supported archs")
[ Make it build only if NO_LIBELF isn't defined, as jitdump.o will only be built in that case ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 621cb4e7837e39d25a5af5a785ad282cdd2b4ce8 upstream.

This patch modifies the build dependencies on the jitdump support in
perf. As it stands jitdump was wrongfully made dependent 100% on using
DWARF. However, the dwarf dependency, only exist if generating the
source line table in genelf_debug.c. The rest of the support does not
need DWARF.

This patch removes the dependency on DWARF for the entire jitdump
support. It keeps it only for the genelf_debug.c support.

Signed-off-by: Maciej Debski &lt;maciejd@google.com&gt;
Reviewed-by: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Anton Blanchard &lt;anton@ozlabs.org&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/1476356383-30100-3-git-send-email-eranian@google.com
Fixes: e12b202f8fb9 ("perf jitdump: Build only on supported archs")
[ Make it build only if NO_LIBELF isn't defined, as jitdump.o will only be built in that case ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>perf pmu: Push configuration down to PMU driver</title>
<updated>2016-09-22T15:19:41+00:00</updated>
<author>
<name>Mathieu Poirier</name>
<email>mathieu.poirier@linaro.org</email>
</author>
<published>2016-09-16T15:50:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=859442bd3fcbe326a9c0174c6105c938eb101438'/>
<id>859442bd3fcbe326a9c0174c6105c938eb101438</id>
<content type='text'>
This patch adds a PMU callback and the required mechanic so that drivers
can process the command line configuration elements found in
evsel::config_terms.

Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-6-git-send-email-mathieu.poirier@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds a PMU callback and the required mechanic so that drivers
can process the command line configuration elements found in
evsel::config_terms.

Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-6-git-send-email-mathieu.poirier@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf annotate: Add branch stack / basic block</title>
<updated>2016-09-08T16:44:03+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2016-09-05T19:08:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=70fbe0574558e934f93bde26e4949c8c206bae43'/>
<id>70fbe0574558e934f93bde26e4949c8c206bae43</id>
<content type='text'>
I wanted to know the hottest path through a function and figured the
branch-stack (LBR) information should be able to help out with that.

The below uses the branch-stack to create basic blocks and generate
statistics from them.

        from    to              branch_i
        * ----&gt; *
                |
                | block
                v
                * ----&gt; *
                from    to      branch_i+1

The blocks are broken down into non-overlapping ranges, while tracking
if the start of each range is an entry point and/or the end of a range
is a branch.

Each block iterates all ranges it covers (while splitting where required
to exactly match the block) and increments the 'coverage' count.

For the range including the branch we increment the taken counter, as
well as the pred counter if flags.predicted.

Using these number we can find if an instruction:

 - had coverage; given by:

        br-&gt;coverage / br-&gt;sym-&gt;max_coverage

   This metric ensures each symbol has a 100% spot, which reflects the
   observation that each symbol must have a most covered/hottest
   block.

 - is a branch target: br-&gt;is_target &amp;&amp; br-&gt;start == add

 - for targets, how much of a branch's coverages comes from it:

	target-&gt;entry / branch-&gt;coverage

 - is a branch: br-&gt;is_branch &amp;&amp; br-&gt;end == addr

 - for branches, how often it was taken:

        br-&gt;taken / br-&gt;coverage

   after all, all execution that didn't take the branch would have
   incremented the coverage and continued onward to a later branch.

 - for branches, how often it was predicted:

        br-&gt;pred / br-&gt;taken

The coverage percentage is used to color the address and asm sections;
for low (&lt;1%) coverage we use NORMAL (uncolored), indicating that these
instructions are not 'important'. For high coverage (&gt;75%) we color the
address RED.

For each branch, we add an asm comment after the instruction with
information on how often it was taken and predicted.

Output looks like (sans color, which does loose a lot of the
information :/)

$ perf record --branch-filter u,any -e cycles:p ./branches 27
$ perf annotate branches

 Percent |	Source code &amp; Disassembly of branches for cycles:pu (217 samples)
---------------------------------------------------------------------------------
         :	branches():
    0.00 :	  40057a:       push   %rbp
    0.00 :	  40057b:       mov    %rsp,%rbp
    0.00 :	  40057e:       sub    $0x20,%rsp
    0.00 :	  400582:       mov    %rdi,-0x18(%rbp)
    0.00 :	  400586:       mov    %rsi,-0x20(%rbp)
    0.00 :	  40058a:       mov    -0x18(%rbp),%rax
    0.00 :	  40058e:       mov    %rax,-0x10(%rbp)
    0.00 :	  400592:       movq   $0x0,-0x8(%rbp)
    0.00 :	  40059a:       jmpq   400656 &lt;branches+0xdc&gt;
    1.84 :	  40059f:       mov    -0x10(%rbp),%rax	# +100.00%
    3.23 :	  4005a3:       and    $0x1,%eax
    1.84 :	  4005a6:       test   %rax,%rax
    0.00 :	  4005a9:       je     4005bf &lt;branches+0x45&gt;	# -54.50% (p:42.00%)
    0.46 :	  4005ab:       mov    0x200bbe(%rip),%rax        # 601170 &lt;acc&gt;
   12.90 :	  4005b2:       add    $0x1,%rax
    2.30 :	  4005b6:       mov    %rax,0x200bb3(%rip)        # 601170 &lt;acc&gt;
    0.46 :	  4005bd:       jmp    4005d1 &lt;branches+0x57&gt;	# -100.00% (p:100.00%)
    0.92 :	  4005bf:       mov    0x200baa(%rip),%rax        # 601170 &lt;acc&gt;	# +49.54%
   13.82 :	  4005c6:       sub    $0x1,%rax
    0.46 :	  4005ca:       mov    %rax,0x200b9f(%rip)        # 601170 &lt;acc&gt;
    2.30 :	  4005d1:       mov    -0x10(%rbp),%rax	# +50.46%
    0.46 :	  4005d5:       mov    %rax,%rdi
    0.46 :	  4005d8:       callq  400526 &lt;lfsr&gt;	# -100.00% (p:100.00%)
    0.00 :	  4005dd:       mov    %rax,-0x10(%rbp)	# +100.00%
    0.92 :	  4005e1:       mov    -0x18(%rbp),%rax
    0.00 :	  4005e5:       and    $0x1,%eax
    0.00 :	  4005e8:       test   %rax,%rax
    0.00 :	  4005eb:       je     4005ff &lt;branches+0x85&gt;	# -100.00% (p:100.00%)
    0.00 :	  4005ed:       mov    0x200b7c(%rip),%rax        # 601170 &lt;acc&gt;
    0.00 :	  4005f4:       shr    $0x2,%rax
    0.00 :	  4005f8:       mov    %rax,0x200b71(%rip)        # 601170 &lt;acc&gt;
    0.00 :	  4005ff:       mov    -0x10(%rbp),%rax	# +100.00%
    7.37 :	  400603:       and    $0x1,%eax
    3.69 :	  400606:       test   %rax,%rax
    0.00 :	  400609:       jne    400612 &lt;branches+0x98&gt;	# -59.25% (p:42.99%)
    1.84 :	  40060b:       mov    $0x1,%eax
   14.29 :	  400610:       jmp    400617 &lt;branches+0x9d&gt;	# -100.00% (p:100.00%)
    1.38 :	  400612:       mov    $0x0,%eax	# +57.65%
   10.14 :	  400617:       test   %al,%al	# +42.35%
    0.00 :	  400619:       je     40062f &lt;branches+0xb5&gt;	# -57.65% (p:100.00%)
    0.46 :	  40061b:       mov    0x200b4e(%rip),%rax        # 601170 &lt;acc&gt;
    2.76 :	  400622:       sub    $0x1,%rax
    0.00 :	  400626:       mov    %rax,0x200b43(%rip)        # 601170 &lt;acc&gt;
    0.46 :	  40062d:       jmp    400641 &lt;branches+0xc7&gt;	# -100.00% (p:100.00%)
    0.92 :	  40062f:       mov    0x200b3a(%rip),%rax        # 601170 &lt;acc&gt;	# +56.13%
    2.30 :	  400636:       add    $0x1,%rax
    0.92 :	  40063a:       mov    %rax,0x200b2f(%rip)        # 601170 &lt;acc&gt;
    0.92 :	  400641:       mov    -0x10(%rbp),%rax	# +43.87%
    2.30 :	  400645:       mov    %rax,%rdi
    0.00 :	  400648:       callq  400526 &lt;lfsr&gt;	# -100.00% (p:100.00%)
    0.00 :	  40064d:       mov    %rax,-0x10(%rbp)	# +100.00%
    1.84 :	  400651:       addq   $0x1,-0x8(%rbp)
    0.92 :	  400656:       mov    -0x8(%rbp),%rax
    5.07 :	  40065a:       cmp    -0x20(%rbp),%rax
    0.00 :	  40065e:       jb     40059f &lt;branches+0x25&gt;	# -100.00% (p:100.00%)
    0.00 :	  400664:       nop
    0.00 :	  400665:       leaveq
    0.00 :	  400666:       retq

(Note: the --branch-filter u,any was used to avoid spurious target and
branch points due to interrupts/faults, they show up as very small -/+
annotations on 'weird' locations)

Committer note:

Please take a look at:

  http://vger.kernel.org/~acme/perf/annotate_basic_blocks.png

To see the colors.

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Anshuman Khandual &lt;khandual@linux.vnet.ibm.com&gt;
Cc: David Carrillo-Cisneros &lt;davidcc@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
[ Moved sym-&gt;max_coverage to 'struct annotate', aka symbol__annotate(sym) ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I wanted to know the hottest path through a function and figured the
branch-stack (LBR) information should be able to help out with that.

The below uses the branch-stack to create basic blocks and generate
statistics from them.

        from    to              branch_i
        * ----&gt; *
                |
                | block
                v
                * ----&gt; *
                from    to      branch_i+1

The blocks are broken down into non-overlapping ranges, while tracking
if the start of each range is an entry point and/or the end of a range
is a branch.

Each block iterates all ranges it covers (while splitting where required
to exactly match the block) and increments the 'coverage' count.

For the range including the branch we increment the taken counter, as
well as the pred counter if flags.predicted.

Using these number we can find if an instruction:

 - had coverage; given by:

        br-&gt;coverage / br-&gt;sym-&gt;max_coverage

   This metric ensures each symbol has a 100% spot, which reflects the
   observation that each symbol must have a most covered/hottest
   block.

 - is a branch target: br-&gt;is_target &amp;&amp; br-&gt;start == add

 - for targets, how much of a branch's coverages comes from it:

	target-&gt;entry / branch-&gt;coverage

 - is a branch: br-&gt;is_branch &amp;&amp; br-&gt;end == addr

 - for branches, how often it was taken:

        br-&gt;taken / br-&gt;coverage

   after all, all execution that didn't take the branch would have
   incremented the coverage and continued onward to a later branch.

 - for branches, how often it was predicted:

        br-&gt;pred / br-&gt;taken

The coverage percentage is used to color the address and asm sections;
for low (&lt;1%) coverage we use NORMAL (uncolored), indicating that these
instructions are not 'important'. For high coverage (&gt;75%) we color the
address RED.

For each branch, we add an asm comment after the instruction with
information on how often it was taken and predicted.

Output looks like (sans color, which does loose a lot of the
information :/)

$ perf record --branch-filter u,any -e cycles:p ./branches 27
$ perf annotate branches

 Percent |	Source code &amp; Disassembly of branches for cycles:pu (217 samples)
---------------------------------------------------------------------------------
         :	branches():
    0.00 :	  40057a:       push   %rbp
    0.00 :	  40057b:       mov    %rsp,%rbp
    0.00 :	  40057e:       sub    $0x20,%rsp
    0.00 :	  400582:       mov    %rdi,-0x18(%rbp)
    0.00 :	  400586:       mov    %rsi,-0x20(%rbp)
    0.00 :	  40058a:       mov    -0x18(%rbp),%rax
    0.00 :	  40058e:       mov    %rax,-0x10(%rbp)
    0.00 :	  400592:       movq   $0x0,-0x8(%rbp)
    0.00 :	  40059a:       jmpq   400656 &lt;branches+0xdc&gt;
    1.84 :	  40059f:       mov    -0x10(%rbp),%rax	# +100.00%
    3.23 :	  4005a3:       and    $0x1,%eax
    1.84 :	  4005a6:       test   %rax,%rax
    0.00 :	  4005a9:       je     4005bf &lt;branches+0x45&gt;	# -54.50% (p:42.00%)
    0.46 :	  4005ab:       mov    0x200bbe(%rip),%rax        # 601170 &lt;acc&gt;
   12.90 :	  4005b2:       add    $0x1,%rax
    2.30 :	  4005b6:       mov    %rax,0x200bb3(%rip)        # 601170 &lt;acc&gt;
    0.46 :	  4005bd:       jmp    4005d1 &lt;branches+0x57&gt;	# -100.00% (p:100.00%)
    0.92 :	  4005bf:       mov    0x200baa(%rip),%rax        # 601170 &lt;acc&gt;	# +49.54%
   13.82 :	  4005c6:       sub    $0x1,%rax
    0.46 :	  4005ca:       mov    %rax,0x200b9f(%rip)        # 601170 &lt;acc&gt;
    2.30 :	  4005d1:       mov    -0x10(%rbp),%rax	# +50.46%
    0.46 :	  4005d5:       mov    %rax,%rdi
    0.46 :	  4005d8:       callq  400526 &lt;lfsr&gt;	# -100.00% (p:100.00%)
    0.00 :	  4005dd:       mov    %rax,-0x10(%rbp)	# +100.00%
    0.92 :	  4005e1:       mov    -0x18(%rbp),%rax
    0.00 :	  4005e5:       and    $0x1,%eax
    0.00 :	  4005e8:       test   %rax,%rax
    0.00 :	  4005eb:       je     4005ff &lt;branches+0x85&gt;	# -100.00% (p:100.00%)
    0.00 :	  4005ed:       mov    0x200b7c(%rip),%rax        # 601170 &lt;acc&gt;
    0.00 :	  4005f4:       shr    $0x2,%rax
    0.00 :	  4005f8:       mov    %rax,0x200b71(%rip)        # 601170 &lt;acc&gt;
    0.00 :	  4005ff:       mov    -0x10(%rbp),%rax	# +100.00%
    7.37 :	  400603:       and    $0x1,%eax
    3.69 :	  400606:       test   %rax,%rax
    0.00 :	  400609:       jne    400612 &lt;branches+0x98&gt;	# -59.25% (p:42.99%)
    1.84 :	  40060b:       mov    $0x1,%eax
   14.29 :	  400610:       jmp    400617 &lt;branches+0x9d&gt;	# -100.00% (p:100.00%)
    1.38 :	  400612:       mov    $0x0,%eax	# +57.65%
   10.14 :	  400617:       test   %al,%al	# +42.35%
    0.00 :	  400619:       je     40062f &lt;branches+0xb5&gt;	# -57.65% (p:100.00%)
    0.46 :	  40061b:       mov    0x200b4e(%rip),%rax        # 601170 &lt;acc&gt;
    2.76 :	  400622:       sub    $0x1,%rax
    0.00 :	  400626:       mov    %rax,0x200b43(%rip)        # 601170 &lt;acc&gt;
    0.46 :	  40062d:       jmp    400641 &lt;branches+0xc7&gt;	# -100.00% (p:100.00%)
    0.92 :	  40062f:       mov    0x200b3a(%rip),%rax        # 601170 &lt;acc&gt;	# +56.13%
    2.30 :	  400636:       add    $0x1,%rax
    0.92 :	  40063a:       mov    %rax,0x200b2f(%rip)        # 601170 &lt;acc&gt;
    0.92 :	  400641:       mov    -0x10(%rbp),%rax	# +43.87%
    2.30 :	  400645:       mov    %rax,%rdi
    0.00 :	  400648:       callq  400526 &lt;lfsr&gt;	# -100.00% (p:100.00%)
    0.00 :	  40064d:       mov    %rax,-0x10(%rbp)	# +100.00%
    1.84 :	  400651:       addq   $0x1,-0x8(%rbp)
    0.92 :	  400656:       mov    -0x8(%rbp),%rax
    5.07 :	  40065a:       cmp    -0x20(%rbp),%rax
    0.00 :	  40065e:       jb     40059f &lt;branches+0x25&gt;	# -100.00% (p:100.00%)
    0.00 :	  400664:       nop
    0.00 :	  400665:       leaveq
    0.00 :	  400666:       retq

(Note: the --branch-filter u,any was used to avoid spurious target and
branch points due to interrupts/faults, they show up as very small -/+
annotations on 'weird' locations)

Committer note:

Please take a look at:

  http://vger.kernel.org/~acme/perf/annotate_basic_blocks.png

To see the colors.

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Anshuman Khandual &lt;khandual@linux.vnet.ibm.com&gt;
Cc: David Carrillo-Cisneros &lt;davidcc@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
[ Moved sym-&gt;max_coverage to 'struct annotate', aka symbol__annotate(sym) ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf probe: Support probing on offline cross-arch binary</title>
<updated>2016-09-01T15:41:09+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2016-08-25T16:24:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=293d5b43948309434568f4dcbb36cce4c3c51bd5'/>
<id>293d5b43948309434568f4dcbb36cce4c3c51bd5</id>
<content type='text'>
Support probing on offline cross-architecture binary by adding getting
the target machine arch from ELF and choose correct register string for
the machine.

Here is an example:
  -----
  $ perf probe --vmlinux=./vmlinux-arm --definition 'do_sys_open $params'
  p:probe/do_sys_open do_sys_open+0 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 mode=%r3:u16
  -----

Here, we can get probe/do_sys_open from above and append it to to the target
machine's tracing/kprobe_events file in the tracefs mountput, usually
/sys/kernel/debug/tracing/kprobe_events (or /sys/kernel/tracing/kprobe_events).

Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/147214229717.23638.6440579792548044658.stgit@devbox
[ Add definition for EM_AARCH64 to fix the build on at least centos 6, debian 7 &amp; ubuntu 12.04.5 ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support probing on offline cross-architecture binary by adding getting
the target machine arch from ELF and choose correct register string for
the machine.

Here is an example:
  -----
  $ perf probe --vmlinux=./vmlinux-arm --definition 'do_sys_open $params'
  p:probe/do_sys_open do_sys_open+0 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 mode=%r3:u16
  -----

Here, we can get probe/do_sys_open from above and append it to to the target
machine's tracing/kprobe_events file in the tracefs mountput, usually
/sys/kernel/debug/tracing/kprobe_events (or /sys/kernel/tracing/kprobe_events).

Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/147214229717.23638.6440579792548044658.stgit@devbox
[ Add definition for EM_AARCH64 to fix the build on at least centos 6, debian 7 &amp; ubuntu 12.04.5 ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools lib api: Add str_error_c to libapi</title>
<updated>2016-07-27T20:16:43+00:00</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2016-07-27T20:09:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8149a774d53afeaf5eb337a813f828f8b8ce68da'/>
<id>8149a774d53afeaf5eb337a813f828f8b8ce68da</id>
<content type='text'>
Because it uses that function, which would lead every tool using it
to need to link against tools/lib/str_error_r.o.

This fixes building tools/vm/, that links with libapi.

Reported-by: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Fixes: b31e3e3316a7 ("tools lib api fs: Use str_error_r()")
Link: http://lkml.kernel.org/n/tip-aedt3qzibhnhaov2j4caqi61@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Because it uses that function, which would lead every tool using it
to need to link against tools/lib/str_error_r.o.

This fixes building tools/vm/, that links with libapi.

Reported-by: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Fixes: b31e3e3316a7 ("tools lib api fs: Use str_error_r()")
Link: http://lkml.kernel.org/n/tip-aedt3qzibhnhaov2j4caqi61@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf symbols: Add Rust demangling</title>
<updated>2016-07-12T19:12:38+00:00</updated>
<author>
<name>David Tolnay</name>
<email>dtolnay@gmail.com</email>
</author>
<published>2016-07-09T07:20:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cae15db74999edb96dd9f5bbd4d55849391dd92b'/>
<id>cae15db74999edb96dd9f5bbd4d55849391dd92b</id>
<content type='text'>
Rust demangling is another step after bfd demangling. Add a diagnosis to
identify mangled Rust symbols based on the hash that the Rust mangler appends
as the last path component, as well as other characteristics.  Add a demangler
to reconstruct the original symbol.

Committer notes:

How I tested it:

Enabled COPR on Fedora 24 and then installed the 'rust-binary' package,
with it:

  $ cat src/main.rs
  fn main() {
      println!("Hello, world!");
  }
  $ cat Cargo.toml
  [package]

  name = "hello_world"
  version = "0.0.1"
  authors = [ "Arnaldo Carvalho de Melo &lt;acme@kernel.org&gt;" ]

  $ perf record cargo bench
   Compiling hello_world v0.0.1 (file:///home/acme/projects/hello_world)
     Running target/release/hello_world-d4b9dab4b2a47d75

  running 0 tests

  test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.096 MB perf.data (1457 samples) ]
  $

Before this patch:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .............................................................................................................
  #
       1.78%  rustc    [.] rbml::reader::maybe_get_doc::hb9d387df6024b15b
       1.50%  rustc    [.] _$LT$reader..DocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::hd9af9e60d79a35c8
       1.20%  rustc    [.] rbml::reader::doc_at::hc88107fba445af31
       0.46%  rustc    [.] _$LT$reader..TaggedDocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::h0cb40e696e4bb489
       0.35%  rustc    [.] rbml::reader::Decoder::_next_int::h66eef7825a398bc3
       0.29%  rustc    [.] rbml::reader::Decoder::_next_sub::h8e5266005580b836
       0.15%  rustc    [.] rbml::reader::get_doc::h094521c645459139
       0.14%  rustc    [.] _$LT$reader..Decoder$LT$$u27$doc$GT$$u20$as$u20$serialize..Decoder$GT$::read_u32::h0acea2fff9669327
       0.07%  rustc    [.] rbml::reader::Decoder::next_doc::h6714d469c9dfaf91
       0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
       0.06%  rustc    [.] _fini
  $

After:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .................................................................
  #
     1.78%  rustc    [.] rbml::reader::maybe_get_doc
     1.50%  rustc    [.] &lt;reader::DocsIterator&lt;'a&gt; as std::iter::Iterator&gt;::next
     1.20%  rustc    [.] rbml::reader::doc_at
     0.46%  rustc    [.] &lt;reader::TaggedDocsIterator&lt;'a&gt; as std::iter::Iterator&gt;::next
     0.35%  rustc    [.] rbml::reader::Decoder::_next_int
     0.29%  rustc    [.] rbml::reader::Decoder::_next_sub
     0.15%  rustc    [.] rbml::reader::get_doc
     0.14%  rustc    [.] &lt;reader::Decoder&lt;'doc&gt; as serialize::Decoder&gt;::read_u32
     0.07%  rustc    [.] rbml::reader::Decoder::next_doc
     0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
     0.06%  rustc    [.] _fini
  $

Signed-off-by: David Tolnay &lt;dtolnay@gmail.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/5780B7FA.3030602@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rust demangling is another step after bfd demangling. Add a diagnosis to
identify mangled Rust symbols based on the hash that the Rust mangler appends
as the last path component, as well as other characteristics.  Add a demangler
to reconstruct the original symbol.

Committer notes:

How I tested it:

Enabled COPR on Fedora 24 and then installed the 'rust-binary' package,
with it:

  $ cat src/main.rs
  fn main() {
      println!("Hello, world!");
  }
  $ cat Cargo.toml
  [package]

  name = "hello_world"
  version = "0.0.1"
  authors = [ "Arnaldo Carvalho de Melo &lt;acme@kernel.org&gt;" ]

  $ perf record cargo bench
   Compiling hello_world v0.0.1 (file:///home/acme/projects/hello_world)
     Running target/release/hello_world-d4b9dab4b2a47d75

  running 0 tests

  test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.096 MB perf.data (1457 samples) ]
  $

Before this patch:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .............................................................................................................
  #
       1.78%  rustc    [.] rbml::reader::maybe_get_doc::hb9d387df6024b15b
       1.50%  rustc    [.] _$LT$reader..DocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::hd9af9e60d79a35c8
       1.20%  rustc    [.] rbml::reader::doc_at::hc88107fba445af31
       0.46%  rustc    [.] _$LT$reader..TaggedDocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::h0cb40e696e4bb489
       0.35%  rustc    [.] rbml::reader::Decoder::_next_int::h66eef7825a398bc3
       0.29%  rustc    [.] rbml::reader::Decoder::_next_sub::h8e5266005580b836
       0.15%  rustc    [.] rbml::reader::get_doc::h094521c645459139
       0.14%  rustc    [.] _$LT$reader..Decoder$LT$$u27$doc$GT$$u20$as$u20$serialize..Decoder$GT$::read_u32::h0acea2fff9669327
       0.07%  rustc    [.] rbml::reader::Decoder::next_doc::h6714d469c9dfaf91
       0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
       0.06%  rustc    [.] _fini
  $

After:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .................................................................
  #
     1.78%  rustc    [.] rbml::reader::maybe_get_doc
     1.50%  rustc    [.] &lt;reader::DocsIterator&lt;'a&gt; as std::iter::Iterator&gt;::next
     1.20%  rustc    [.] rbml::reader::doc_at
     0.46%  rustc    [.] &lt;reader::TaggedDocsIterator&lt;'a&gt; as std::iter::Iterator&gt;::next
     0.35%  rustc    [.] rbml::reader::Decoder::_next_int
     0.29%  rustc    [.] rbml::reader::Decoder::_next_sub
     0.15%  rustc    [.] rbml::reader::get_doc
     0.14%  rustc    [.] &lt;reader::Decoder&lt;'doc&gt; as serialize::Decoder&gt;::read_u32
     0.07%  rustc    [.] rbml::reader::Decoder::next_doc
     0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
     0.06%  rustc    [.] _fini
  $

Signed-off-by: David Tolnay &lt;dtolnay@gmail.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/r/5780B7FA.3030602@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf tools: Uninline scnprintf() and vscnprint()</title>
<updated>2016-07-12T18:20:24+00:00</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2016-07-07T18:42:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d0761e37fe3fed7810ed8d6e130b79359f0c3e13'/>
<id>d0761e37fe3fed7810ed8d6e130b79359f0c3e13</id>
<content type='text'>
They were in tools/include/linux/kernel.h, requiring that it in turn
included stdio.h, which is way too heavy.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/n/tip-855h8olnkot9v0dajuee1lo3@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
They were in tools/include/linux/kernel.h, requiring that it in turn
included stdio.h, which is way too heavy.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/n/tip-855h8olnkot9v0dajuee1lo3@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools: Introduce str_error_r()</title>
<updated>2016-07-12T18:19:47+00:00</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2016-07-06T14:56:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c8b5f2c96d1bf6cefcbe12f67dce0b892fe20512'/>
<id>c8b5f2c96d1bf6cefcbe12f67dce0b892fe20512</id>
<content type='text'>
The tools so far have been using the strerror_r() GNU variant, that
returns a string, be it the buffer passed or something else.

But that, besides being tricky in cases where we expect that the
function using strerror_r() returns the error formatted in a provided
buffer (we have to check if it returned something else and copy that
instead), breaks the build on systems not using glibc, like Alpine
Linux, where musl libc is used.

So, introduce yet another wrapper, str_error_r(), that has the GNU
interface, but uses the portable XSI variant of strerror_r(), so that
users rest asured that the provided buffer is used and it is what is
returned.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/n/tip-d4t42fnf48ytlk8rjxs822tf@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The tools so far have been using the strerror_r() GNU variant, that
returns a string, be it the buffer passed or something else.

But that, besides being tricky in cases where we expect that the
function using strerror_r() returns the error formatted in a provided
buffer (we have to check if it returned something else and copy that
instead), breaks the build on systems not using glibc, like Alpine
Linux, where musl libc is used.

So, introduce yet another wrapper, str_error_r(), that has the GNU
interface, but uses the portable XSI variant of strerror_r(), so that
users rest asured that the provided buffer is used and it is what is
returned.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/n/tip-d4t42fnf48ytlk8rjxs822tf@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf callchain: Support aarch64 cross-platform</title>
<updated>2016-06-07T18:13:35+00:00</updated>
<author>
<name>He Kuang</name>
<email>hekuang@huawei.com</email>
</author>
<published>2016-06-03T03:33:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=057fbfb25cde4a368418f3f720cdc31d48800c4d'/>
<id>057fbfb25cde4a368418f3f720cdc31d48800c4d</id>
<content type='text'>
Support aarch64 cross platform callchain unwind.

Signed-off-by: He Kuang &lt;hekuang@huawei.com&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ekaterina Tumanova &lt;tumanova@linux.vnet.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Sukadev Bhattiprolu &lt;sukadev@linux.vnet.ibm.com&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/r/1464924803-22214-15-git-send-email-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support aarch64 cross platform callchain unwind.

Signed-off-by: He Kuang &lt;hekuang@huawei.com&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ekaterina Tumanova &lt;tumanova@linux.vnet.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Sukadev Bhattiprolu &lt;sukadev@linux.vnet.ibm.com&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/r/1464924803-22214-15-git-send-email-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf callchain: Support x86 target platform</title>
<updated>2016-06-07T18:13:27+00:00</updated>
<author>
<name>He Kuang</name>
<email>hekuang@huawei.com</email>
</author>
<published>2016-06-03T03:33:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=52ffe0ff02fc053a025c381d5808e9ecd3206dfe'/>
<id>52ffe0ff02fc053a025c381d5808e9ecd3206dfe</id>
<content type='text'>
Support x86(32-bit) cross platform callchain unwind.

Signed-off-by: He Kuang &lt;hekuang@huawei.com&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ekaterina Tumanova &lt;tumanova@linux.vnet.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Sukadev Bhattiprolu &lt;sukadev@linux.vnet.ibm.com&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/r/1464924803-22214-14-git-send-email-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support x86(32-bit) cross platform callchain unwind.

Signed-off-by: He Kuang &lt;hekuang@huawei.com&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ekaterina Tumanova &lt;tumanova@linux.vnet.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Sukadev Bhattiprolu &lt;sukadev@linux.vnet.ibm.com&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Link: http://lkml.kernel.org/r/1464924803-22214-14-git-send-email-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
