1. 11 2月, 2015 1 次提交
  2. 07 2月, 2015 2 次提交
  3. 06 2月, 2015 5 次提交
  4. 30 1月, 2015 6 次提交
  5. 28 1月, 2015 1 次提交
    • V
      perf evsel: Don't rely on malloc working for sz 0 · 8d9cbd8f
      Vineet Gupta 提交于
      When running perf on ARC (uClibc based userspace), ran into this issue
         ------------->8----------------
      	[ARCLinux]$ ./perf record ls
      	bin             etc             perf            sys
      	debug           init            perf.data       tmp
      	[ perf record: Woken up 1 times to write data ]
      	[ perf record: Captured and wrote 0.001 MB perf.data (~24 samples) ]
      
      	[ARCLinux]$ ./perf report
      	incompatible file format (rerun with -v to learn more)
         ------------->8----------------
      
      The problem happens in the following call stack when zalloc is called
      with size zero
      
      glibc default / uClibc with MALLOC_GLIBC_COMPAT are OK, but not if that
      config option is not enabled.
      
        cmd_report
           perf_session__new
      	perf_session__open
      	    perf_session__read_header
      		read_attr(fd, header, &f_attr)
      		nr_ids = f_attr.ids.size / sizeof(u64); <-- 0
      		perf_evsel__alloc_id(vsel, 1, nr_ids)
      			zalloc(ncpus * nthreads * sizeof(u64)) <-- 0
      
      header.c: read_attr()
      
      (gdb) p *f_attr
      $17 = {
        attr = {
          type = 0,
          size = 96,
          config = 0,
          {
            sample_period = 4000,
            sample_freq = 4000
          },
      ...
        ids = {
          offset = 104,
          size = 0      <------
        }
      }
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Suggested-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1421156604-30603-5-git-send-email-vgupta@synopsys.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8d9cbd8f
  6. 22 1月, 2015 10 次提交
  7. 21 1月, 2015 8 次提交
  8. 17 1月, 2015 6 次提交
    • N
      perf tools: Fix segfault for symbol annotation on TUI · 813ccd15
      Namhyung Kim 提交于
      Currently the symbol structure is allocated with symbol_conf.priv_size
      to carry sideband information like annotation, map browser on TUI and
      sort-by-name tree node.  So retrieving these information from symbol
      needs to care about the details of such placement.
      
      However the annotation code just assumes that the symbol is placed after
      the struct annotation.  But actually there's other info between them.
      So accessing those struct will lead to an undefined behavior (usually a
      crash) after they write their info to the same location.
      
      To reproduce the problem, please follow the steps below:
      
        1. run perf report (TUI of course) with -v option
        2. open map browser (by pressing right arrow key for any entry)
        3. search any function (by pressing '/' key and input whatever..)
        4. return to the hist browser (by pressing 'q' or left arrow key)
        5. open annotation window for the same entry (by pressing 'a' key)
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      813ccd15
    • W
      perf test: Fix dwarf unwind using libunwind. · b93b0967
      Wang Nan 提交于
      Perf tool fails to unwind user stack if the event raises in a shared
      object. This patch improves tests/dwarf-unwind.c to demonstrate the
      problem by utilizing commonly used glibc function "bsearch". If perf is
      not statically linked, the testcase will try to unwind a mixed call
      trace.
      
      By debugging libunwind I found that there is a bug in unwind-libunwind:
      it always passes 0 as segbase to libunwind, cause libunwind unable to
      locate debug_frame entry fir first level ip address (I add some more
      debugging output into libunwind to make things clear):
      
                     >_Uarm_dwarf_find_debug_frame: start_ip = 10be98, end_ip = 10c2a4
                     >_Uarm_dwarf_find_debug_frame: found debug_frame table `/lib/libc-2.18.so': segbase=0x0, len=7, gp=0x0, table_data=0x449388
                     >_Uarm_dwarf_search_unwind_table: call lookup:ip = b6cd3bcc, segbase = 0, rel_ip = b6cd3bcc
                     >lookup: e->start_ip_offset = bcf18 (rel_ip = b6cd3bcc)
                     >lookup: e->start_ip_offset = 6d314 (rel_ip = b6cd3bcc)
                     >lookup: e->start_ip_offset = 33d0c (rel_ip = b6cd3bcc)
                      ...
                     >lookup: e->start_ip_offset = 15d0c (rel_ip = b6cd3bcc)
                     >lookup: e->start_ip_offset = 15c40 (rel_ip = b6cd3bcc)
       >_Uarm_dwarf_search_unwind_table: IP b6cd3bcc inside range b6c12000-b6d4c000, but no explicit unwind info found
                      >put_rs_cache: unmasking signals/interrupts and releasing lock
                     >_Uarm_dwarf_step: returning -10
       >_Uarm_step: dwarf_step()=-10
      
      This patch passes map->start as segbase to dwarf_find_debug_frame(), so
      di will be initialized correctly.
      
      In addition, dso and executable are different when setting segbase. This
      patch first check whether the elf is executable, and pass segbase only
      for shared object.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1421203007-75799-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b93b0967
    • V
      perf tools: Elide strlcpy warning with uclibc · a83d869f
      Vineet Gupta 提交于
         ----------------->8------------------
        CC       bench/sched-pipe.o
      In file included from builtin-annotate.c:13:0:
      util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy'
      [-Wredundant-decls]
       extern size_t strlcpy(char *dest, const char *src, size_t size);
                     ^
      In file included from util/util.h:55:0,
                       from builtin.h:4,
                       from builtin-annotate.c:8:
      ~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15:
      note: previous declaration of 'strlcpy' was here
       extern size_t strlcpy(char *__restrict dst, const char *__restrict src,
         ----------------->8------------------
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgupta@synopsys.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a83d869f
    • A
      tools: Remove bitops/hweight usage of bits in tools/perf · 25cd480e
      Arnaldo Carvalho de Melo 提交于
      We need to use lib/hweight.c for that, just like we do for lib/rbtree.c,
      so tools need to link hweight.o. For now do it directly, but we need to
      have a tools/lib/lk.a or .so that collects these goodies...
      Reported-by: NJan Beulich <JBeulich@suse.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-a1e91dx3apzqw5kbdt7ut21s@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      25cd480e
    • N
      perf machine: Fix __machine__findnew_thread() error path · 260d819e
      Namhyung Kim 提交于
      When thread__init_map_groups() fails, a new thread should be removed
      from the rbtree since it's gonna be freed.  Also update last match cache
      only if the function succeeded.
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      260d819e
    • N
      perf probe: Propagate error code when write(2) failed · 7949ba1f
      Namhyung Kim 提交于
      When it failed to write probe commands to the probe_event file in
      debugfs, it needs to propagate the error code properly.  Current code
      blindly uses the return value of the write(2) so it always uses
      -1 (-EPERM) and it might confuse users.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1420886028-15135-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7949ba1f
  9. 08 1月, 2015 1 次提交