1. 14 9月, 2015 1 次提交
  2. 04 9月, 2015 2 次提交
  3. 06 7月, 2015 1 次提交
  4. 12 5月, 2015 1 次提交
    • H
      perf probe: Add --range option to show a variable's location range · 349e8d26
      He Kuang 提交于
      It is not easy for users to get the accurate byte offset or the line
      number where a local variable can be probed.
      
      With '--range' option, local variables in the scope of the probe point
      are showed with a byte offset range, and can be added according to this
      range information.
      
      For example, there are some variables in the function
      generic_perform_write():
      
        <generic_perform_write@mm/filemap.c:0>
        0  ssize_t generic_perform_write(struct file *file,
        1                                 struct iov_iter *i, loff_t pos)
        2  {
        3          struct address_space *mapping = file->f_mapping;
        4          const struct address_space_operations *a_ops = mapping->a_ops;
        ...
        42                 status = a_ops->write_begin(file, mapping, pos, bytes, flags,
                                                     &page, &fsdata);
        44                 if (unlikely(status < 0))
      
      But we fail when we try to probe the variable 'a_ops' at line 42 or 44.
      
        $ perf probe --add 'generic_perform_write:42 a_ops'
        Failed to find the location of a_ops at this address.
          Perhaps, it has been optimized out.
      
      This is because the source code do not match the assembly, so a variable
      may not be available in the source code line where it appears.
      
      After this patch, we can lookup the accurate byte offset range of a
      variable, 'INV' indicates that this variable is not valid at the given
      point, but available in the scope:
      
        $ perf probe --vars 'generic_perform_write:42' --range
        Available variables at generic_perform_write:42
          @<generic_perform_write+141>
             [INV] ssize_t written @<generic_perform_write+[324-331]>
             [INV] struct address_space_operations*        a_ops   @<generic_perform_write+[55-61,170-176,223-246]>
             [VAL] (unknown_type)  fsdata  @<generic_perform_write+[70-307,346-411]>
             [VAL] loff_t  pos     @<generic_perform_write+[0-286,286-336,346-411]>
             [VAL] long int        status  @<generic_perform_write+[83-342,346-411]>
             [VAL] long unsigned int       bytes   @<generic_perform_write+[122-311,320-338,346-403,403-411]>
             [VAL] struct address_space*   mapping @<generic_perform_write+[35-344,346-411]>
             [VAL] struct iov_iter*        i       @<generic_perform_write+[0-340,346-411]>
             [VAL] struct page*    page    @<generic_perform_write+[70-307,346-411]>
      
      Then it is more clear for us to add a probe with this variable:
      
        $ perf probe --add 'generic_perform_write+170 a_ops'
        Added new event:
          probe:generic_perform_write (on generic_perform_write+170 with a_ops)
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1431336304-16863-2-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      349e8d26
  5. 09 5月, 2015 4 次提交
  6. 06 5月, 2015 4 次提交
  7. 04 5月, 2015 2 次提交
  8. 29 4月, 2015 1 次提交
  9. 10 4月, 2015 2 次提交
  10. 29 10月, 2014 3 次提交
  11. 18 9月, 2014 2 次提交
  12. 15 8月, 2014 1 次提交
  13. 10 6月, 2014 1 次提交
    • M
      perf probe: Show error code and description in verbose mode · b4bf1130
      Masami Hiramatsu 提交于
      Show error code and description only in verbose mode if 'perf probe'
      command failed.
      
      Current 'perf probe' shows error code with final error message, and that
      is meaningless for many users.
      
      This changes error messages to show the error code and its description
      only in verbose mode (-v option).
      
      Without this patch:
        -----
        # perf probe -a do_execve@hoge
        Probe point 'do_execve@hoge' not found.
          Error: Failed to add events. (-2)
        -----
      
      With this patch, normally the message doesn't show the misterious error
      number:
        -----
        # perf probe -a do_execve@hoge
        Probe point 'do_execve@hoge' not found.
          Error: Failed to add events.
        -----
      
      And in verbose mode, it also shows additional error messages as below:
        -----
        # perf probe -va do_execve@hoge
        probe-definition(0): do_execve@hoge
        symbol:do_execve file:hoge line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (6 entries long)
        Using /lib/modules/3.15.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/3.15.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Probe point 'do_execve@hoge' not found.
          Error: Failed to add events. Reason: No such file or directory (Code: -2)
        -----
      Reported-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      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/20140606071352.6788.76943.stgit@kbuild-fedora.novalocalSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b4bf1130
  14. 18 2月, 2014 1 次提交
  15. 17 1月, 2014 1 次提交
  16. 26 12月, 2013 2 次提交
    • M
      perf probe: Support basic dwarf-based operations on uprobe events · fb7345bb
      Masami Hiramatsu 提交于
      Support basic dwarf(debuginfo) based operations for uprobe events.  With
      this change, perf probe can analyze debuginfo of user application binary
      to set up new uprobe event.
      
      This allows perf-probe --add(with local variables, line numbers) and
      --line works with -x option.  (Actually, --vars has already accepted -x
      option)
      
      For example, the following command shows the probe-able lines of a given
      user space function. Something that so far was only available in the
      'perf probe' tool for kernel space functions:
      
        # ./perf probe -x perf --line map__load
        <map__load@/home/fedora/ksrc/linux-2.6/tools/perf/util/map.c:0>
              0  int map__load(struct map *map, symbol_filter_t filter)
              1  {
              2         const char *name = map->dso->long_name;
                        int nr;
      
              5         if (dso__loaded(map->dso, map->type))
              6                 return 0;
      
              8         nr = dso__load(map->dso, map, filter);
              9         if (nr < 0) {
             10                 if (map->dso->has_build_id) {
      
      And this shows the available variables at the given line of the
      function.
      
        # ./perf probe -x perf --vars map__load:8
        Available variables at map__load:8
                @<map__load+96>
                        char*   name
                        struct map*     map
                        symbol_filter_t filter
                @<map__find_symbol+112>
                        char*   name
                        symbol_filter_t filter
                @<map__find_symbol_by_name+136>
                        char*   name
                        symbol_filter_t filter
                @<map_groups__find_symbol_by_name+176>
                        char*   name
                        struct map*     map
                        symbol_filter_t filter
      
      And lastly, we can now define probe(s) with all available
      variables on the given line:
      
        # ./perf probe -x perf --add 'map__load:8 $vars'
      
        Added new events:
          probe_perf:map__load (on map__load:8 with $vars)
          probe_perf:map__load_1 (on map__load:8 with $vars)
          probe_perf:map__load_2 (on map__load:8 with $vars)
          probe_perf:map__load_3 (on map__load:8 with $vars)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe_perf:map__load_3 -aR sleep 1
      
        Changes from previous version:
         - Add examples in the patch description.
         - Use .text section start address and dwarf symbol address
           for calculating the offset of given symbol, instead of
           searching the symbol in symtab again.
           With this change, we can safely handle multiple local
           function instances (e.g. scnprintf in perf).
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David A. Long <dave.long@linaro.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: systemtap@sourceware.org
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20131226054152.22364.47021.stgit@kbuild-fedora.novalocalSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fb7345bb
    • M
      perf probe: Expand given path to absolute path · 8a613d40
      Masami Hiramatsu 提交于
      Expand given path to absolute path in the option parser, except for a
      module name.
      
      Since realpath at later stage in processing several probe point, can be
      called several times (even if currently doesn't, it can happen when we
      expands the feature), it is waste of the performance.
      
      Processing it once at the early stage can avoid that.
      
      Changes from previous one:
       - Fix not to print null string.
       - Allocate memory for given path/module name everytime.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: systemtap@sourceware.org
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20131226054150.22364.12187.stgit@kbuild-fedora.novalocal
      [ Clarified the pr_warning message as per David Ahern's suggestion ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8a613d40
  17. 17 12月, 2013 1 次提交
    • B
      tools/: Convert to new topic libraries · 553873e1
      Borislav Petkov 提交于
      Move debugfs.* to api/fs/. We have a common tools/lib/api/ place where
      the Makefile lives and then we place the headers in subdirs.
      
      For example, all the fs-related stuff goes to tools/lib/api/fs/ from
      which we get libapikfs.a (acme got almost the naming he wanted :-)) and
      we link it into the tools which need it - in this case perf and
      tools/vm/page-types.
      
      acme:
      
      "Looking at the implementation, I think some tools can even link
      directly to the .o files, avoiding the .a file altogether.
      
      But that is just an optimization/finer granularity tools/lib/
      cherrypicking that toolers can make use of."
      
      Fixup documentation cleaning target while at it.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Stanislav Fomichev <stfomichev@yandex-team.ru>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1386605664-24041-2-git-send-email-bp@alien8.deSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      553873e1
  18. 15 11月, 2013 1 次提交
  19. 09 10月, 2013 1 次提交
  20. 16 3月, 2013 1 次提交
  21. 03 10月, 2012 1 次提交
  22. 11 9月, 2012 1 次提交
    • I
      perf tools: Use __maybe_used for unused variables · 1d037ca1
      Irina Tirdea 提交于
      perf defines both __used and __unused variables to use for marking
      unused variables. The variable __used is defined to
      __attribute__((__unused__)), which contradicts the kernel definition to
      __attribute__((__used__)) for new gcc versions. On Android, __used is
      also defined in system headers and this leads to warnings like: warning:
      '__used__' attribute ignored
      
      __unused is not defined in the kernel and is not a standard definition.
      If __unused is included everywhere instead of __used, this leads to
      conflicts with glibc headers, since glibc has a variables with this name
      in its headers.
      
      The best approach is to use __maybe_unused, the definition used in the
      kernel for __attribute__((unused)). In this way there is only one
      definition in perf sources (instead of 2 definitions that point to the
      same thing: __used and __unused) and it works on both Linux and Android.
      This patch simply replaces all instances of __used and __unused with
      __maybe_unused.
      Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1347315303-29906-7-git-send-email-irina.tirdea@intel.com
      [ committer note: fixed up conflict with a116e05d in builtin-sched.c ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1d037ca1
  23. 12 5月, 2012 2 次提交
    • S
      perf probe: Detect probe target when m/x options are absent · 73eff9f5
      Srikar Dronamraju 提交于
      Options -m and -x explicitly allow tracing of modules / user space
      binaries. In absense of these options, check if the first argument can
      be used as a target.
      
      perf probe /bin/zsh zfree is equivalent to perf probe -x /bin/zsh zfree.
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Arapov <anton@redhat.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jim Keniston <jkenisto@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux-mm <linux-mm@kvack.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20120416120925.30661.40409.sendpatchset@srdronam.in.ibm.comSigned-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      73eff9f5
    • S
      perf probe: Provide perf interface for uprobes · 225466f1
      Srikar Dronamraju 提交于
      - Enhances perf to probe user space executables and libraries.
      - Enhances -F/--funcs option of "perf probe" to list possible probe points in
        an executable file or library.
      - Documents userspace probing support in perf.
      
      [ Probing a function in the executable using function name  ]
      perf probe -x /bin/zsh zfree
      
      [ Probing a library function using function name ]
      perf probe -x /lib64/libc.so.6 malloc
      
      [ list probe-able functions in an executable ]
      perf probe -F -x /bin/zsh
      
      [ list probe-able functions in an library]
      perf probe -F -x /lib/libc.so.6
      Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Arapov <anton@redhat.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jim Keniston <jkenisto@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux-mm <linux-mm@kvack.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20120416120909.30661.99781.sendpatchset@srdronam.in.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      225466f1
  24. 03 2月, 2012 1 次提交
  25. 31 1月, 2012 1 次提交
    • D
      perf tools: Fix broken build by defining _GNU_SOURCE in Makefile · 0a84f007
      David Daney 提交于
      When building on my Debian/mips system, util/util.c fails to build
      because commit 1aed2671 (perf kvm: Do
      guest-only counting by default) indirectly includes stdio.h before the
      feature selection in util.h is done.  This prevents _GNU_SOURCE in
      util.h from enabling the declaration of getline(), from now second
      inclusion of stdio.h, and the build is broken.
      
      There is another breakage in util/evsel.c caused by include ordering,
      but I didn't fully track down the commit that caused it.
      
      The root cause of all this is an inconsistent definition of _GNU_SOURCE,
      so I move the definition into the Makefile so that it is passed to all
      invocations of the compiler and used uniformly for all system header
      files.  All other #define and #undef of _GNU_SOURCE are removed as they
      cause conflicts with the definition passed to the compiler.
      
      All the features.h definitions (_LARGEFILE64_SOURCE _FILE_OFFSET_BITS=64
      and _GNU_SOURCE) are needed by the python glue code too, so they are
      moved to BASIC_CFLAGS, and the misleading comments about BASIC_CFLAGS
      are removed.
      
      This gives me a clean build on x86_64 (fc12) and mips (Debian).
      
      Cc: David Daney <david.daney@cavium.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1326836461-11952-1-git-send-email-ddaney.cavm@gmail.comSigned-off-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a84f007
  26. 25 1月, 2012 1 次提交
    • D
      perf tools: Fix broken build by defining _GNU_SOURCE in Makefile · 2ef1ea38
      David Daney 提交于
      When building on my Debian/mips system, util/util.c fails to build
      because commit 1aed2671 (perf kvm: Do
      guest-only counting by default) indirectly includes stdio.h before the
      feature selection in util.h is done.  This prevents _GNU_SOURCE in
      util.h from enabling the declaration of getline(), from now second
      inclusion of stdio.h, and the build is broken.
      
      There is another breakage in util/evsel.c caused by include ordering,
      but I didn't fully track down the commit that caused it.
      
      The root cause of all this is an inconsistent definition of _GNU_SOURCE,
      so I move the definition into the Makefile so that it is passed to all
      invocations of the compiler and used uniformly for all system header
      files.  All other #define and #undef of _GNU_SOURCE are removed as they
      cause conflicts with the definition passed to the compiler.
      
      All the features.h definitions (_LARGEFILE64_SOURCE _FILE_OFFSET_BITS=64
      and _GNU_SOURCE) are needed by the python glue code too, so they are
      moved to BASIC_CFLAGS, and the misleading comments about BASIC_CFLAGS
      are removed.
      
      This gives me a clean build on x86_64 (fc12) and mips (Debian).
      
      Cc: David Daney <david.daney@cavium.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1326836461-11952-1-git-send-email-ddaney.cavm@gmail.comSigned-off-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2ef1ea38