An error occurred fetching the project authors.
  1. 14 May, 2015 1 commit
    • Naveen N. Rao's avatar
      perf probe: Ignore tail calls to probed functions · d4c537e6
      Naveen N. Rao authored
      perf probe currently errors out if there are any tail calls to probed
      functions:
      
      [root@rhel71be]# perf probe do_fork
      Failed to find probe point in any functions.
        Error: Failed to add events.
      
      Fix this by teaching perf to ignore tail calls.
      
      Without patch:
      
        [root@rhel71be perf]# ./perf probe -v do_fork
        probe-definition(0): do_fork symbol:do_fork file:(null) line:0 offset:0
        return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (7 entries long)
        symsrc__init: build id mismatch for /boot/vmlinux.
        Using /usr/lib/debug/lib/modules/3.10.0-201.el7.ppc64/vmlinux for symbols
        Open Debuginfo file:
        /usr/lib/debug/lib/modules/3.10.0-201.el7.ppc64/vmlinux
        Try to find probe point from debuginfo.
        found inline addr: 0xc0000000000bb9b0
        Probe point found: do_fork+0
        found inline addr: 0xc0000000000bbe20
        Probe point found: kernel_thread+48
        found inline addr: 0xc0000000000bbe5c
        Probe point found: sys_fork+28
        found inline addr: 0xc0000000000bbfac
        Probe point found: sys_vfork+44
        found inline addr: 0xc0000000000bc27c
        Failed to find probe point in any functions.
        An error occurred in debuginfo analysis (-2).
        Error: Failed to add events. Reason: No such file or directory (Code: -2)
      
      With patch:
      
        [root@rhel71be perf]# ./perf probe -v do_fork
        probe-definition(0): do_fork symbol:do_fork file:(null) line:0 offset:0
        return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (7 entries long)
        symsrc__init: build id mismatch for /boot/vmlinux.
        Using /usr/lib/debug/lib/modules/3.10.0-201.el7.ppc64/vmlinux for symbols
        Open Debuginfo file:
        /usr/lib/debug/lib/modules/3.10.0-201.el7.ppc64/vmlinux
        Try to find probe point from debuginfo.
        found inline addr: 0xc0000000000bb9b0
        Probe point found: do_fork+0
        found inline addr: 0xc0000000000bbe20
        Probe point found: kernel_thread+48
        found inline addr: 0xc0000000000bbe5c
        Probe point found: sys_fork+28
        found inline addr: 0xc0000000000bbfac
        Probe point found: sys_vfork+44
        found inline addr: 0xc0000000000bc27c
        Ignoring tail call from SyS_clone
        Found 4 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        No kprobe blacklist support, ignored
        Added new events:
        Writing event: p:probe/do_fork _text+768432
        Failed to write event: Invalid argument
          Error: Failed to add events. Reason: Invalid argument (Code: -22)
      
      [Ignore the error about failure to write event - this kernel is missing
      a patch to resolve _text properly]
      
      The reason to ignore tail calls is that the address does not belong to
      any function frame. In the example above, the address in SyS_clone is
      0xc0000000000bc27c, but looking at the debug-info:
      
       <1><830081>: Abbrev Number: 133 (DW_TAG_subprogram)
          <830083>   DW_AT_external    : 1
          <830083>   DW_AT_name        : (indirect string, offset: 0x3cea3): SyS_clone
          <830087>   DW_AT_decl_file   : 7
          <830088>   DW_AT_decl_line   : 1689
          <83008a>   DW_AT_prototyped  : 1
          <83008a>   DW_AT_type        : <0x8110eb>
          <83008e>   DW_AT_low_pc      : 0xc0000000000bc270
          <830096>   DW_AT_high_pc     : 0xc
          <83009e>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
          <8300a0>   DW_AT_GNU_all_call_sites: 1
          <8300a0>   DW_AT_sibling     : <0x830178>
      <snip>
       <3><830147>: Abbrev Number: 125 (DW_TAG_GNU_call_site)
          <830148>   DW_AT_low_pc      : 0xc0000000000bc27c
          <830150>   DW_AT_GNU_tail_call: 1
          <830150>   DW_AT_abstract_origin: <0x82e7e1>
      
      The frame ends at 0xc0000000000bc27c. I suppose this is why this
      particular call is a "tail" call. FWIW, systemtap seems to ignore these
      as well and requires users to explicitly place probes at these call
      sites if necessary. I print out the caller so that users know.
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/1430394151-15928-1-git-send-email-naveen.n.rao@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d4c537e6
  2. 12 May, 2015 2 commits
    • He Kuang's avatar
      perf probe: Add --range option to show a variable's location range · 349e8d26
      He Kuang authored
      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: default avatarHe Kuang <hekuang@huawei.com>
      Acked-by: default avatarMasami 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: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      349e8d26
    • He Kuang's avatar
      perf probe: Remove length limitation for showing available variables · fb9596d1
      He Kuang authored
      Use struct strbuf instead of bare char[] to remove the length limitation
      of variables in variable_list, so they will not disappear due to
      overlength, and make preparation for adding more description for
      variables.
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Acked-by: default avatarMasami 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-1-git-send-email-hekuang@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      fb9596d1
  3. 08 May, 2015 1 commit
    • Masami Hiramatsu's avatar
      perf probe: Support glob wildcards for function name · 4c859351
      Masami Hiramatsu authored
      Support glob wildcards for function name when adding new probes. This
      will allow us to build caches of function-entry level information with
      $params.
      
      e.g.
        ----
        # perf probe --no-inlines --add 'kmalloc* $params'
        Added new events:
          probe:kmalloc_slab   (on kmalloc* with $params)
          probe:kmalloc_large_node (on kmalloc* with $params)
          probe:kmalloc_order_trace (on kmalloc* with $params)
      
        You can now use it in all perf tools, such as:
      
              perf record -e probe:kmalloc_order_trace -aR sleep 1
      
        # perf probe --list
          probe:kmalloc_large_node (on kmalloc_large_node@mm/slub.c with size flags node)
          probe:kmalloc_order_trace (on kmalloc_order_trace@mm/slub.c with size flags order)
          probe:kmalloc_slab   (on kmalloc_slab@mm/slab_common.c with size flags)
        ----
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150508010335.24812.19972.stgit@localhost.localdomainSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      4c859351
  4. 06 Feb, 2015 1 commit
  5. 04 Oct, 2013 1 commit
    • Masami Hiramatsu's avatar
      perf probe: Fix to find line information for probe list · e08cfd4b
      Masami Hiramatsu authored
      Fix to find the correct (as much as possible) line information for
      listing probes. Without this fix, perf probe --list action will show
      incorrect line information as below;
      
        probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_1 (on getname:-89@x86/include/asm/current.h)
        probe:getname_flags_2 (on user_path_at_empty:-2054@x86/include/asm/current.h)
      
      The minus line number is obviously wrong, and current.h is not related
      to the probe point. Deeper investigation discovered that there were 2
      issues related to this bug, and minor typos too.
      
      The 1st issue is the rack of considering about nested inlined functions,
      which causes the wrong (relative) line number.
      
      The 2nd issue is that the dwarf line info is not correct at those
      points. It points 14th line of current.h.
      
      Since it seems that the line info includes somewhat unreliable
      information, this fixes perf to try to find correct line information
      from both of debuginfo and line info as below.
      
      1) Probe address is the entry of a function instance
      
        In this case, the line is set as the function declared line.
      
      2) Probe address is the entry of an expanded inline function block
      
        In this case, the line is set as the function call-site line.
        This means that the line number is relative from the entry line
        of caller function (which can be an inlined function if nested)
      
      3) Probe address is inside a function instance or an expanded
         inline function block
      
        In this case, perf probe queries the line number from lineinfo
        and verify the function declared file is same as the file name
        queried from lineinfo.
      
        If the file name is different, it is a failure case. The probe
        address is shown as symbol+offset.
      
      4) Probe address is not in the any function instance
      
        This is a failure case, the probe address is shown as
        symbol+offset.
      
      With this fix, perf probe -l shows correct probe lines as below;
      
        probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_1 (on getname:2@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_2 (on user_path_at_empty:4@ksrc/linux-3/fs/namei.c)
      
      Changes at v2:
       - Fix typos in the function comments. (Thanks to Namhyung Kim)
       - Use die_find_top_inlinefunc instead of die_find_inlinefunc_next.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@redhat.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/20130930092144.1693.11058.stgit@udc4-manage.rcp.hitachi.co.jpSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e08cfd4b
  6. 19 Sep, 2013 1 commit
  7. 12 Aug, 2011 3 commits
    • Masami Hiramatsu's avatar
      perf probe: Search concrete out-of-line instances · db0d2c64
      Masami Hiramatsu authored
      gcc 4.6 generates a concrete out-of-line instance when there is a
      function which is implicitly inlined somewhere but also has its own
      instance. The concrete out-of-line instance means that it has an
      abstract origin of the function which is referred by not only
      inlined-subroutines but also a concrete subprogram.
      
      Since current dwarf_func_inline_instances() can find only instances of
      inlined-subroutines, this introduces new die_walk_instances() to find
      both of subprogram and inlined-subroutines.
      
      e.g. without this,
      Available variables at sched_group_rt_period
              @<cpu_rt_period_read_uint+9>
                      struct task_group*      tg
      
      perf probe failed to find actual subprogram instance of
      sched_group_rt_period().
      
      With this,
      
      Available variables at sched_group_rt_period
              @<cpu_rt_period_read_uint+9>
                      struct task_group*      tg
              @<sched_group_rt_period+0>
                      struct task_group*      tg
      
      Now it found the sched_group_rt_period() itself.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110311.19900.63997.stgit@fedora15Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      db0d2c64
    • Masami Hiramatsu's avatar
      perf probe: Fix to search local variables in appropriate scope · 221d0611
      Masami Hiramatsu authored
      Fix perf probe to search local variables in appropriate local inlined
      function scope. For example, pre_schedule() has only 2 local variables,
      as below;
      
      $ perf probe -L pre_schedule
      <pre_schedule@/home/mhiramat/ksrc/linux-2.6/kernel/sched.c:0>
            0  static inline void pre_schedule(struct rq *rq, struct task_struct *prev)
               {
            2         if (prev->sched_class->pre_schedule)
            3                 prev->sched_class->pre_schedule(rq, prev);
               }
      
      However, current perf probe shows 4 local variables on pre_schedule(),
      because it searches variables in the caller(schedule()) scope.
      
      $ perf probe -V pre_schedule
      Available variables at pre_schedule
              @<schedule+445>
                      int     cpu
                      long unsigned int*      switch_count
                      struct rq*      rq
                      struct task_struct*     prev
      
      This patch fixes this issue by searching variables in the local scope of
      the instance of inlined function. Here is the result.
      
      $ perf probe -V pre_schedule
      Available variables at pre_schedule
              @<schedule+445>
                      struct rq*      rq
                      struct task_struct*     prev
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110259.19900.85664.stgit@fedora15Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      221d0611
    • Masami Hiramatsu's avatar
      perf probe: Fix to search nested inlined functions in CU · b0e9cb28
      Masami Hiramatsu authored
      Fix perf probe to walk through the lines of all nested inlined function
      call sites and declared lines when a whole CU is passed to the line
      walker.
      
      The die_walk_lines() can have two different type of DIEs, subprogram (or
      inlined-subroutine) DIE and CU DIE.
      
      If a caller passes a subprogram DIE, this means that the walker walk on
      lines of given subprogram. In this case, it just needs to search on
      direct children of DIE tree for finding call-site information of inlined
      function which directly called from given subprogram.
      
      On the other hand, if a caller passes a CU DIE to the walker, this means
      that the walker have to walk on all lines in the source files included
      in given CU DIE. In this case, it has to search whole DIE trees of all
      subprograms to find the call-site information of all nested inlined
      functions.
      
      Without this patch:
      
      $ perf probe --line kernel/cpu.c:151-157
      </home/mhiramat/ksrc/linux-2.6/kernel/cpu.c:151>
      
               static int cpu_notify(unsigned long val, void *v)
               {
          154         return __cpu_notify(val, v, -1, NULL);
               }
      
      With this:
      $ perf probe --line kernel/cpu.c:151-157
      </home/mhiramat/ksrc/linux-2.6/kernel/cpu.c:151>
      
          152  static int cpu_notify(unsigned long val, void *v)
               {
          154         return __cpu_notify(val, v, -1, NULL);
               }
      
      As you can see, --line option with source line range shows the declared
      lines as probe-able.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110241.19900.34994.stgit@fedora15Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b0e9cb28
  8. 15 Jul, 2011 1 commit