1. 24 10月, 2017 1 次提交
  2. 12 8月, 2017 1 次提交
  3. 24 5月, 2017 3 次提交
    • M
      perf report: Do not drop last inlined frame · 4d53b9d5
      Milian Wolff 提交于
      The very last inlined frame, i.e. the one furthest away from the
      non-inlined frame, was silently dropped. This is apparent when
      comparing the output of `perf script` and `addr2line`:
      
      ~~~~~~
        $ perf script --inline
        ...
        a.out 26722 80836.309329:      72425 cycles:
                           21561 __hypot_finite (/usr/lib/libm-2.25.so)
                            ace3 hypot (/usr/lib/libm-2.25.so)
                             a4a main (a.out)
                                 std::abs<double>
                                 std::_Norm_helper<true>::_S_do_it<double>
                                 std::norm<double>
                                 main
                           20510 __libc_start_main (/usr/lib/libc-2.25.so)
                             bd9 _start (a.out)
      
        $ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
        0x0000000000000a4a
        std::__complex_abs(doublecomplex )
        /usr/include/c++/6.3.1/complex:589
        double std::abs<double>(std::complex<double> const&)
        /usr/include/c++/6.3.1/complex:597
        double std::_Norm_helper<true>::_S_do_it<double>(std::complex<double> const&)
        /usr/include/c++/6.3.1/complex:654
        double std::norm<double>(std::complex<double> const&)
        /usr/include/c++/6.3.1/complex:664
        main
        /tmp/inlining.cpp:14
      ~~~~~
      
      Note how `std::__complex_abs` is missing from the `perf script`
      output. This is similarly showing up in `perf report`. The patch
      here fixes this issue, and the output becomes:
      
      ~~~~~
        a.out 26722 80836.309329:      72425 cycles:
                           21561 __hypot_finite (/usr/lib/libm-2.25.so)
                            ace3 hypot (/usr/lib/libm-2.25.so)
                             a4a main (a.out)
                                 std::__complex_abs
                                 std::abs<double>
                                 std::_Norm_helper<true>::_S_do_it<double>
                                 std::norm<double>
                                 main
                           20510 __libc_start_main (/usr/lib/libc-2.25.so)
                             bd9 _start (a.out)
      ~~~~~
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Cc: kernel-team@lge.com
      Link: http://lkml.kernel.org/r/20170524062129.32529-7-namhyung@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4d53b9d5
    • M
      perf report: Always honor callchain order for inlined nodes · 28071f51
      Milian Wolff 提交于
      So far, the inlined nodes where only reversed when we built perf
      against libbfd. If that was not available, the addr2line fallback
      code path was missing the inline_list__reverse call.
      
      Now we always add the nodes in the correct order within
      inline_list__append. This removes the need to reverse the list
      and also ensures that all callers construct the list in the right
      order.
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Cc: kernel-team@lge.com
      Link: http://lkml.kernel.org/r/20170524062129.32529-6-namhyung@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      28071f51
    • M
      perf report: Fix memory leak in addr2line when called by addr2inlines · b21cc978
      Milian Wolff 提交于
      When a filename was found in addr2line it was duplicated via strdup()
      but never freed. Now we pass NULL and handle this gracefully in
      addr2line.
      
      Detected by Valgrind:
      
        ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 220
        ==16331==    at 0x4C2AF1F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
        ==16331==    by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
        ==16331==    by 0x52769F: addr2line (srcline.c:256)
        ==16331==    by 0x52769F: addr2inlines (srcline.c:294)
        ==16331==    by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
        ==16331==    by 0x574D7A: inline__fprintf (hist.c:41)
        ==16331==    by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
        ==16331==    by 0x57518A: __callchain__fprintf_graph (hist.c:212)
        ==16331==    by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
        ==16331==    by 0x57738E: hist_entry__fprintf (hist.c:628)
        ==16331==    by 0x57738E: hists__fprintf (hist.c:882)
        ==16331==    by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
        ==16331==    by 0x44A20F: report__browse_hists (builtin-report.c:491)
        ==16331==    by 0x44A20F: __cmd_report (builtin-report.c:624)
        ==16331==    by 0x44A20F: cmd_report (builtin-report.c:1054)
        ==16331==    by 0x4A49CE: run_builtin (perf.c:296)
        ==16331==    by 0x4A4CC0: handle_internal_command (perf.c:348)
        ==16331==    by 0x434371: run_argv (perf.c:392)
        ==16331==    by 0x434371: main (perf.c:530)
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Cc: kernel-team@lge.com
      Link: http://lkml.kernel.org/r/20170524062129.32529-3-namhyung@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b21cc978
  4. 20 4月, 2017 2 次提交
  5. 27 3月, 2017 3 次提交
    • M
      perf report: Enable sorting by srcline as key · 5dfa210e
      Milian Wolff 提交于
      Often it is interesting to know how costly a given source line is in
      total. Previously, one had to build these sums manually based on all
      addresses that pointed to the same source line. This patch introduces
      srcline as a sort key, which will do the aggregation for us.
      
      Paired with the recent addition of showing inline frames, this makes
      perf report much more useful for many C++ work loads.
      
      The following shows the new feature in action. First, let's show the
      status quo output when we sort by address. The result contains many hist
      entries that generate the same output:
      
        ~~~~~~~~~~~~~~~~
        $ perf report --stdio --inline -g address
        # Children      Self  Command       Shared Object        Symbol
        # ........  ........  ............  ...................  .........................................
        #
            99.89%    35.34%  cpp-inlining  cpp-inlining         [.] main
                  |
                  |--64.55%--main complex:655
                  |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                  |          /usr/include/c++/6.3.1/complex:664 (inline)
                  |          |
                  |          |--60.31%--hypot +20
                  |          |          |
                  |          |          |--8.52%--__hypot_finite +273
                  |          |          |
                  |          |          |--7.32%--__hypot_finite +411
      ...
                   --35.34%--_start +4194346
                             __libc_start_main +241
                             |
                             |--6.65%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
                             |
                             |--2.70%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
                             |
                             |--1.69%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
        ...
        ~~~~~~~~~~~~~~~~
      
      With this patch and `-g srcline` we instead get the following output:
      
        ~~~~~~~~~~~~~~~~
        $ perf report --stdio --inline -g srcline
        # Children      Self  Command       Shared Object        Symbol
        # ........  ........  ............  ...................  .........................................
        #
            99.89%    35.34%  cpp-inlining  cpp-inlining         [.] main
                  |
                  |--64.55%--main complex:655
                  |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                  |          /usr/include/c++/6.3.1/complex:664 (inline)
                  |          |
                  |          |--64.02%--hypot
                  |          |          |
                  |          |           --59.81%--__hypot_finite
                  |          |
                  |           --0.53%--cabs
                  |
                   --35.34%--_start
                             __libc_start_main
                             |
                             |--12.48%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
        ...
        ~~~~~~~~~~~~~~~~
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Link: http://lkml.kernel.org/r/20170318214928.9047-1-milian.wolff@kdab.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5dfa210e
    • J
      perf report: Find the inline stack for a given address · a64489c5
      Jin Yao 提交于
      It would be useful for perf to support a mode to query the inline stack
      for a given callgraph address. This would simplify finding the right
      code in code that does a lot of inlining.
      
      The srcline.c has contained the code which supports to translate the
      address to filename:line_nr. This patch just extends the function to let
      it support getting the inline stacks.
      
      It introduces the inline_list which will store the inline function
      result (filename:line_nr and funcname).
      
      If BFD lib is not supported, the result is only filename:line_nr.
      Signed-off-by: NYao Jin <yao.jin@linux.intel.com>
      Tested-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Link: http://lkml.kernel.org/r/1490474069-15823-3-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a64489c5
    • J
      perf report: Refactor common code in srcline.c · 5580338d
      Jin Yao 提交于
      Introduce dso__name() and filename_split() out of existing code because
      these codes will be used in several places in next patch.
      
      For filename_split(), it may also solve a potential memory leak in
      existing code. In existing addr2line(),
      
              sep = strchr(filename, ':');
              if (sep) {
                      *sep++ = '\0';
                      *file = filename;
                      *line_nr = strtoul(sep, NULL, 0);
                      ret = 1;
              }
      
      out:
              pclose(fp);
              return ret;
      
      If sep is NULL, filename is not freed or returned via file.
      Signed-off-by: NYao Jin <yao.jin@linux.intel.com>
      Tested-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Link: http://lkml.kernel.org/r/1490474069-15823-2-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5580338d
  6. 03 9月, 2015 1 次提交
    • A
      perf tools: Always use non inlined file name for 'srcfile' sort key · 2f84b42b
      Andi Kleen 提交于
      When profiling the kernel with the 'srcfile' sort key it's common to
      "get stuck" in include. For example a lot of code uses current or other
      inlines, so they get accounted to some random include file. This is not
      very useful as a high level categorization.
      
      For example just profiling the idle loop usually shows mostly inlines,
      so you never see the actual cpuidle file.
      
      This patch changes the 'srcfile' sort key to always unwind the inline
      stack using BFD/DWARF. So we always account to the base function that
      called the inline.
      
      In a few cases include is still shown (for example for MSR accesses),
      but that is because they get inlining expanded as part of assigning to a
      global function pointer. For the majority it works fine though.
      
      v2: Use simpler while loop. Add maximum iteration count.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/1441133239-31254-1-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2f84b42b
  7. 10 8月, 2015 1 次提交
  8. 19 12月, 2014 1 次提交
    • W
      perf: Fix building warning on ARM 32 · ac931f87
      Wang Nan 提交于
      Commit 85c116a6 ("perf callchain: Make get_srcline fall back to sym+offset")
      introduces asprintf() call and matches '%ld' to a u64 argument, which is
      incorrect on ARM:
      
         CC       /home/wn/util/srcline.o
       util/srcline.c: In function 'get_srcline':
       util/srcline.c:297:6: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Werror=format]
       cc1: all warnings being treated as errors
       make[1]: *** [/home/wn/util/srcline.o] Error 1
      
      In addition, all users of get_srcline() use u64 addr, and libbfd
      also use 64 bit bfd_vma as address. This patch also fix
      prototype of get_srcline() and addr2line() to use u64 addr
      instead of unsigned long.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: <lizefan@huawei.com>
      Cc: <a.p.zijlstra@chello.nl>
      Cc: <paulus@samba.org>
      Cc: <acme@kernel.org>
      Cc: <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/1418710746-35943-1-git-send-email-wangnan0@huawei.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ac931f87
  9. 25 11月, 2014 2 次提交
  10. 19 11月, 2014 1 次提交
  11. 16 1月, 2014 1 次提交
    • N
      perf tools: Fix build error due to zfree() cast · 7d16c634
      Namhyung Kim 提交于
      It failed to build perf on my ubuntu 10.04 box (gcc 4.4.3):
      
          CC       util/strlist.o
        cc1: warnings being treated as errors
        util/strlist.c: In function ‘str_node__delete’:
        util/strlist.c:42: error: dereferencing type-punned pointer will break strict-aliasing rules
        util/strlist.c:42: error: dereferencing type-punned pointer will break strict-aliasing rules
          CC       util/strfilter.o
        make: *** [util/strlist.o] Error 1
      
          CC       util/srcline.o
        cc1: warnings being treated as errors
        util/srcline.c: In function ‘addr2line_init’:
        util/srcline.c:132: error: dereferencing type-punned pointer will break strict-aliasing rules
        util/srcline.c:132: error: dereferencing type-punned pointer will break strict-aliasing rules
        util/srcline.c: In function ‘addr2line_cleanup’:
        util/srcline.c:143: error: dereferencing type-punned pointer will break strict-aliasing rules
        util/srcline.c:143: error: dereferencing type-punned pointer will break strict-aliasing rules
        make: *** [util/srcline.o] Error 1
      
      It seems it only allows to remove 'const' qualifier.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1389276479-9047-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7d16c634
  12. 28 12月, 2013 1 次提交
  13. 11 12月, 2013 1 次提交
  14. 05 12月, 2013 4 次提交
  15. 14 10月, 2013 1 次提交
    • D
      perf tools: Fix old GCC build error in 'get_srcline' · a949fffb
      David Ahern 提交于
      trace-event-parse.c:parse_proc_kallsyms()
      
          Old GCC (4.4.2) does not see through the code flow of get_srcline() and
      gets confused about the status of 'file' and 'line':
      
          CC       /tmp/build/perf/util/srcline.o
        cc1: warnings being treated as errors
        util/srcline.c: In function ¿get_srcline¿:
        util/srcline.c:226: error: ¿file¿ may be used uninitialized in this function
        util/srcline.c:227: error: ¿line¿ may be used uninitialized in this function
        make[1]: *** [/tmp/build/perf/util/srcline.o] Error 1
        make: *** [install] Error 2
        make: Leaving directory `/home/acme/git/linux/tools/perf'
        [acme@fedora12 linux]$
      
      Help out GCC by initializing 'file' and 'line'.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Link: http://lkml.kernel.org/n/tip-h8k7h49z3cndqgjdftkmm9f8@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a949fffb
  16. 10 10月, 2013 5 次提交
新手
引导
客服 返回
顶部