linux-toradex.git/tools/perf/util/srcline.c, branch v6.3-rc3

perf srcline: Conditionally suppress addr2line warnings

2022-12-21T17:52:40+00:00

It has symbol_conf.disable_add2line_warn to suppress some warnings.  Let's
make it consistent with others.

Signed-off-by: Namhyung Kim 
Acked-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Leo Yan 
Cc: Milian Wolff 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20221215192817.2734573-6-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf srcline: Skip srcline if .debug_line is missing

2022-12-21T17:52:40+00:00

The srcline info is from the .debug_line section.  No need to setup
addr2line subprocess if the section is missing.

Signed-off-by: Namhyung Kim 
Acked-by: Ian Rogers 
Link: https://lore.kernel.org/r/20221215192817.2734573-5-namhyung@kernel.org
Cc: Peter Zijlstra 
Cc: Adrian Hunter 
Cc: Milian Wolff 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Ingo Molnar 
Cc: Leo Yan 
Cc: Andi Kleen 
Cc: LKML 
Cc: linux-perf-users@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf srcline: Do not return NULL for srcline

2022-12-21T17:52:40+00:00

The code assumes non-NULL srcline value always, let's return the usual
SRCLINE_UNKNOWN ("??:0") string instead.

Signed-off-by: Namhyung Kim 
Acked-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Leo Yan 
Cc: Milian Wolff 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20221215192817.2734573-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf srcline: Use long-running addr2line per DSO

2021-10-04T12:29:07+00:00

Invoking addr2line in a separate subprocess, one for each required
lookup, takes a terribly long time.

This patch introduces a long-running addr2line process for each DSO,
*DRAMATICALLY* speeding up runs of perf.

What used to take tens of minutes now takes tens of seconds.

Debian bug report about this issue:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815

Signed-off-by: Tony Garnock-Jones 
Tested-by: Ian Rogers 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20210916120939.453536-1-tonyg@leastfixedpoint.com
Signed-off-by: Arnaldo Carvalho de Melo

perf: Make perf able to build with latest libbfd

2020-01-30T10:55:26+00:00

libbfd has changed the bfd_section_* macros to inline functions
bfd_section_ since 2019-09-18. See below two commits:
  o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html
  o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html

This fix make perf able to build with both old and new libbfd.

Signed-off-by: Changbin Du 
Acked-by: Jiri Olsa 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo

tools lib: Adopt zalloc()/zfree() from tools/perf

2019-07-09T13:13:26+00:00

Eroding a bit more the tools/perf/util/util.h hodpodge header.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-natazosyn9rwjka25tvcnyi0@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf diff: Print the basic block cycles diff

2019-07-02T16:20:51+00:00

 $ perf record -b ./div
 $ perf record -b ./div

Following is the default perf diff output

 $ perf diff

 # Event 'cycles'
 #
 # Baseline  Delta Abs  Shared Object     Symbol
 # ........  .........  ................  ..................................
 #
     48.75%     +0.33%  div               [.] main
      8.21%     -0.20%  div               [.] compute_flag
     19.02%     -0.12%  libc-2.23.so      [.] __random_r
     16.17%     -0.09%  libc-2.23.so      [.] __random
      2.27%     -0.03%  div               [.] rand@plt
                +0.02%  [i915]            [k] gen8_irq_handler
      5.52%     +0.02%  libc-2.23.so      [.] rand

This patch creates a new computation selection 'cycles'.

 $ perf diff -c cycles

 # Event 'cycles'
 #
 # Baseline       [Program Block Range] Cycles Diff Shared Object Symbol
 # ........ ....................................... .........................................
 #
     48.75%             [div.c:42 -> div.c:45]  147 div           [.] main
     48.75%             [div.c:31 -> div.c:40]    4 div           [.] main
     48.75%             [div.c:40 -> div.c:40]    0 div           [.] main
     48.75%             [div.c:42 -> div.c:42]    0 div           [.] main
     48.75%             [div.c:42 -> div.c:44]    0 div           [.] main
     19.02% [random_r.c:357 -> random_r.c:360]    0 libc-2.23.so  [.] __random_r
     19.02% [random_r.c:357 -> random_r.c:373]    0 libc-2.23.so  [.] __random_r
     19.02% [random_r.c:357 -> random_r.c:376]    0 libc-2.23.so  [.] __random_r
     19.02% [random_r.c:357 -> random_r.c:380]    0 libc-2.23.so  [.] __random_r
     19.02% [random_r.c:357 -> random_r.c:392]    0 libc-2.23.so  [.] __random_r
     16.17%     [random.c:288 -> random.c:291]    0 libc-2.23.so  [.] __random
     16.17%     [random.c:288 -> random.c:291]    0 libc-2.23.so  [.] __random
     16.17%     [random.c:288 -> random.c:295]    0 libc-2.23.so  [.] __random
     16.17%     [random.c:288 -> random.c:297]    0 libc-2.23.so  [.] __random
     16.17%     [random.c:291 -> random.c:291]    0 libc-2.23.so  [.] __random
     16.17%     [random.c:293 -> random.c:293]    0 libc-2.23.so  [.] __random
      8.21%             [div.c:22 -> div.c:22]  148 div           [.] compute_flag
      8.21%             [div.c:22 -> div.c:25]    0 div           [.] compute_flag
      8.21%             [div.c:27 -> div.c:28]    0 div           [.] compute_flag
      5.52%           [rand.c:26 -> rand.c:27]    0 libc-2.23.so  [.] rand
      5.52%           [rand.c:26 -> rand.c:28]    0 libc-2.23.so  [.] rand
      2.27%         [rand@plt+0 -> rand@plt+0]    0 div           [.] rand@plt
      0.01% [entry_64.S:694 -> entry_64.S:694]   16 [vmlinux]     [k] native_irq_return_iret
      0.00%       [fair.c:7676 -> fair.c:7665]  162 [vmlinux]     [k] update_blocked_averages

"[Program Block Range]" indicates the range of program basic block
(start -> end). If we can find the source line it prints the source line
otherwise it prints the symbol+offset instead.

 v4:
 ---
 Use source lines or symbol+offset to indicate the basic block. It should
 be easier to understand.

 v3:
 ---
 Cast 'struct hist_entry' to 'struct block_hist' in hist_entry__block_fprintf.
 Use symbol_conf.report_block to check if executing hist_entry__block_fprintf.

 v2:
 ---
 Keep standard perf diff format and display the 'Baseline' and
 'Shared Object'.

The output is sorted by "Baseline" and the basic blocks in the same
function are sorted by cycles diff.

Signed-off-by: Jin Yao 
Reviewed-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1561713784-30533-7-git-send-email-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Ditch rtrim(), use strim() from tools/lib

2019-07-02T01:50:33+00:00

Cleaning up a bit more tools/perf/util/ by using things we got from the
kernel and have in tools/lib/

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-7hluuoveryoicvkclshzjf1k@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf report: Don't shadow inlined symbol with different addr range

2019-02-19T15:30:12+00:00

We can't assume inlined symbols with the same name are equal, because
their address range may be different. This will cause the symbols with
different addresses be shadowed when adding to the hist entry, and lead
to ERANGE error when checking the symbol address during sample parse,
the addr should be within the range of [sym.start, sym.end].

The error message is like: "0x36aea60 [0x8]: failed to process type: 68".

The second parameter of symbol__new() is the length of the fake symbol
for the inline frame, which is the subtraction of the end and start
address of base_sym.

Signed-off-by: He Kuang 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Fixes: aa441895f7b4 ("perf report: Compare symbol name for inlined frames when sorting")
Link: http://lkml.kernel.org/r/20190219130531.15692-1-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Use cached rbtrees

2019-01-25T14:12:09+00:00

At the cost of an extra pointer, we can avoid the O(logN) cost of
finding the first element in the tree (smallest node), which is
something required for nearly every in/srcline callchain node deletion
(in/srcline__tree_delete()).

Signed-off-by: Davidlohr Bueso 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181206191819.30182-4-dave@stgolabs.net
Signed-off-by: Arnaldo Carvalho de Melo