1. 13 11月, 2015 1 次提交
    • A
      perf symbols: Rebuild rbtree when adjusting symbols for kcore · 866548dd
      Adrian Hunter 提交于
      Normally symbols are read from the DSO and adjusted, if need be, so that
      the symbol start matches the file offset in the DSO file (we want the
      file offset because that is what we know from MMAP events). That is done
      by dso__load_sym() which inserts the symbols *after* adjusting them.
      
      In the case of kcore, the symbols have been read from kallsyms and the
      symbol start is the memory address. The symbols have to be adjusted to
      match the kcore file offsets. dso__split_kallsyms_for_kcore() does that,
      but now the adjustment is being done *after* the symbols have been
      inserted. It appears dso__split_kallsyms_for_kcore() was assuming that
      changing the symbol start would not change the order in the rbtree -
      which is, of course, not guaranteed.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: NWang Nan <wangnan0@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/563CB241.2090701@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      866548dd
  2. 28 10月, 2015 2 次提交
  3. 13 10月, 2015 1 次提交
    • A
      perf symbols: Try the .debug/ DSO cache as a last resort · dc38218e
      Arnaldo Carvalho de Melo 提交于
      Not as the first attempt at finding a vmlinux for the running kernel,
      this way we get a more informative filename to present in tools, it will
      check that the build-id is the same as the one previously loaded in the
      DSO in dso->build_id, reading from /sys/kernel/notes, for instance.
      
      E.g. in the annotation TUI, going from 'perf top', for the scsi_sg_alloc
      kernel function, in the first line:
      
      Before:
      
      scsi_sg_alloc  /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1
      
      After:
      
      scsi_sg_alloc  /lib/modules/4.3.0-rc1+/build/vmlinux
      
      And:
      
        # ls -la /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1
      lrwxrwxrwx. 1 root root 81 Sep 22 16:11 /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1 -> ../../home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
        # file ~/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
      /root/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=282777c262e6b3c0451375163c9a81c893218ab1, not stripped
        #
      
      The same as:
      
        # file /lib/modules/4.3.0-rc1+/build/vmlinux
      /lib/modules/4.3.0-rc1+/build/vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=282777c262e6b3c0451375163c9a81c893218ab1, not stripped
      
      Furthermore:
      
        # sha256sum /lib/modules/4.3.0-rc1+/build/vmlinux
        e7a789bbdc61029ec09140c228e1dd651271f38ef0b8416c0b7d5ff727b98be2  /lib/modules/4.3.0-rc1+/build/vmlinux
        # sha256sum ~/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
        e7a789bbdc61029ec09140c228e1dd651271f38ef0b8416c0b7d5ff727b98be2  /root/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
        [root@zoo new]#
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-9y42ikzq3jisiddoi6f07n8z@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dc38218e
  4. 01 10月, 2015 1 次提交
  5. 29 8月, 2015 1 次提交
  6. 25 8月, 2015 1 次提交
    • A
      perf annotate: Reset the dso find_symbol cache when removing symbols · c0b4dffb
      Arnaldo Carvalho de Melo 提交于
      The 'annotate' tool does some filtering in the entries in a DSO but
      forgot to reset the cache done in dso__find_symbol(), cauxing a SEGV:
      
        [root@zoo ~]# perf annotate netlink_poll
        perf: Segmentation fault
        -------- backtrace --------
        perf[0x526ceb]
        /lib64/libc.so.6(+0x34960)[0x7faedfbe0960]
        perf(rb_erase+0x223)[0x499d63]
        perf[0x4213e9]
        perf[0x4bc123]
        perf[0x4bc621]
        perf[0x4bf26b]
        perf[0x4bc855]
        perf(perf_session__process_events+0x340)[0x4bddc0]
        perf(cmd_annotate+0x6bb)[0x421b5b]
        perf[0x479063]
        perf(main+0x60a)[0x42098a]
        /lib64/libc.so.6(__libc_start_main+0xf0)[0x7faedfbcbfe0]
        perf[0x420aa9]
        [0x0]
        [root@zoo ~]#
      
      Fix it by reseting the find cache when removing symbols.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Fixes: b685ac22 ("perf symbols: Add front end cache for DSO symbol lookup")
      Link: http://lkml.kernel.org/n/tip-b2y9x46y0t8yem1ive41zqyp@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c0b4dffb
  7. 21 8月, 2015 1 次提交
  8. 23 7月, 2015 1 次提交
  9. 20 7月, 2015 1 次提交
  10. 13 7月, 2015 1 次提交
    • A
      perf symbols: Store if there is a filter in place · 0bc2f2f7
      Arnaldo Carvalho de Melo 提交于
      When setting yup the symbols library we setup several filter lists,
      for dsos, comms, symbols, etc, and there is code that, if there are
      filters, do certain operations, like recalculate the number of non
      filtered histogram entries in the top/report TUI.
      
      But they were considering just the "Zoom" filters, when they need to
      take into account as well the above mentioned filters (perf top --comms,
      --dsos, etc).
      
      So store in symbol_conf.has_filter true if any of those filters is in
      place.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-f5edfmhq69vfvs1kmikq1wep@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0bc2f2f7
  11. 26 6月, 2015 1 次提交
    • L
      perf symbols: Check access permission when reading symbol files · 36c8bb56
      Li Zhang 提交于
      There 2 problems when reading symbols files:
      
      *  It doesn't report any errors even if when users specify symbol
         files which don't exist with --kallsyms or --vmlinux. The result
         just shows the address without symbols, which is not what is expected.
         So it's better to report errors and exit the program.
      
      *  When using command perf report --kallsyms=/proc/kallsyms with a
         non-root user, symbols are resolved. Then select one symbol and
         annotate it, it reports the error as the following:
         Can't annotate __clear_user: No vmlinux file with build id xxx was
         found.
      
         The problem is caused by reading /proc/kcore without access permission.
         /proc/kcore requires CAP_SYS_RAWIO capability to access, so it needs to
         change access permission to allow a specific user to read /proc/kcore or
         use root to execute the perf command.
      
      This patch is to report errors when symbol files specified by users
      don't exist. And check access permission of /proc/kcore when reading it.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1434704253-2632-1-git-send-email-zhlcindy@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36c8bb56
  12. 08 6月, 2015 2 次提交
    • A
      perf tools: Reference count struct dso · d3a7c489
      Arnaldo Carvalho de Melo 提交于
      This has a different model than the 'thread' and 'map' struct lifetimes:
      there is not a definitive "don't use this DSO anymore" event, i.e. we may
      get many 'struct map' holding references to the '/usr/lib64/libc-2.20.so'
      DSO but then at some point some DSO may have no references but we still
      don't want to straight away release its resources, because "soon" we may
      get a new 'struct map' that needs it and we want to reuse its symtab or
      other resources.
      
      So we need some way to garbage collect it when crossing some memory
      usage threshold, which is left for anoter patch, for now it is
      sufficient to release it when calling dsos__exit(), i.e. when deleting
      the whole list as part of deleting the 'struct machine' containing it,
      which will leave only referenced objects being used.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/n/tip-majzgz07cm90t2tejrjy4clf@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d3a7c489
    • A
      perf machine: Fix up some more method names · 9f2de315
      Arnaldo Carvalho de Melo 提交于
      Calling the function 'machine__new_module' implies a new 'module' will
      be allocated, when in fact what is returned is a 'struct map' instance,
      that not necessarily will be instantiated, as if one already exists with
      the given module name, it will be returned instead.
      
      So be consistent with other "find and if not there, create" like
      functions, like machine__findnew_thread, machine__findnew_dso, etc, and
      rename it to machine__findnew_module_map(), that in turn will call
      machine__findnew_module_dso().
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/n/tip-acv830vd3hwww2ih5vjtbmu3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9f2de315
  13. 28 5月, 2015 4 次提交
  14. 27 5月, 2015 2 次提交
  15. 18 5月, 2015 2 次提交
  16. 04 5月, 2015 2 次提交
  17. 08 4月, 2015 1 次提交
  18. 25 3月, 2015 1 次提交
  19. 22 1月, 2015 1 次提交
  20. 21 1月, 2015 2 次提交
  21. 05 11月, 2014 1 次提交
    • N
      perf record: Do not save pathname in ./debug/.build-id directory for vmlinux · 00dc8657
      Namhyung Kim 提交于
      When perf record finishes a session, it pre-processes samples in order
      to write build-id info from DSOs that had samples.
      
      During this process it'll call map__load() for the kernel map, and it
      ends up calling dso__load_vmlinux_path() which replaces dso->long_name.
      
      But this function checks kernel's build-id before searching vmlinux path
      so it'll end up with a cryptic name, the pathname for the entry in the
      ~/.debug cache, which can be confusing to users.
      
      This patch adds a flag to skip the build-id check during record, so
      that it'll have the original vmlinux path for the kernel dso->long_name,
      not the entry in the ~/.debug cache.
      
      Before:
        # perf record -va sleep 3
        mmap size 528384B
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.196 MB perf.data (~8545 samples) ]
        Looking at the vmlinux_path (7 entries long)
        Using /home/namhyung/.debug/.build-id/f0/6e17aa50adf4d00b88925e03775de107611551 for symbols
      
      After:
        # perf record -va sleep 3
        mmap size 528384B
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.193 MB perf.data (~8432 samples) ]
        Looking at the vmlinux_path (7 entries long)
        Using /lib/modules/3.16.4-1-ARCH/build/vmlinux for symbols
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1415063674-17206-7-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      00dc8657
  22. 04 11月, 2014 1 次提交
  23. 15 10月, 2014 2 次提交
  24. 18 9月, 2014 2 次提交
  25. 14 8月, 2014 2 次提交
  26. 13 8月, 2014 2 次提交
  27. 31 7月, 2014 1 次提交