Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 7月, 2015 1 次提交
  3. 08 6月, 2015 1 次提交
    • 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
  5. 14 5月, 2015 1 次提交
    • N
      perf probe: Ignore tail calls to probed functions · d4c537e6
      由 Naveen N. Rao 提交于 
      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: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: NMasami 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      d4c537e6
  7. 12 5月, 2015 3 次提交
    • H
      perf probe: Show better error message when failed to find variable · 7d5eaba9
      由 He Kuang 提交于 
      Indicate to check variable location range in error message when we got
failed to find the variable.

Before this patch:

  $ perf probe --add 'generic_perform_write+118 bytes'
  Failed to find the location of bytes at this address.
   Perhaps, it has been optimized out.
    Error: Failed to add events.

After this patch:

  $ perf probe --add 'generic_perform_write+118 bytes'
  Failed to find the location of the 'bytes' variable at this address.
   Perhaps it has been optimized out.
   Use -V with the --range option to show 'bytes' location range.
    Error: Failed to add events.
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-3-git-send-email-hekuang@huawei.com
[ Improve the error message based on lkml thread ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7d5eaba9
    • 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
    • H
      perf probe: Remove length limitation for showing available variables · fb9596d1
      由 He Kuang 提交于 
      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: 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-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fb9596d1
  9. 09 5月, 2015 4 次提交
    • M
      perf probe: Support glob wildcards for function name · 4c859351
      由 Masami Hiramatsu 提交于 
      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: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: NArnaldo 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      4c859351
    • M
      perf probe: Add --no-inlines option to avoid searching inline functions · 6cfd1f68
      由 Masami Hiramatsu 提交于 
      Add --no-inlines(--inlines) option to avoid searching inline functions.

Searching all functions which matches glob pattern can take a long time
and find a lot of inline functions.

With this option perf-probe searches target on the non-inlined
functions.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.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/20150508010333.24812.86568.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6cfd1f68
    • M
      perf probe: Introduce probe_conf global configs · ddb2f58f
      由 Masami Hiramatsu 提交于 
      Introduce probe_conf global configuration parameters for probe-event and
probe-finder, and removes related parameters from APIs.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.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/20150508010330.24812.21095.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ddb2f58f
    • M
      perf probe: Support $params special probe argument · f8bffbf1
      由 Masami Hiramatsu 提交于 
      $params is similar to $vars but matches only function parameters not
local variables.

Thus, this is useful for tracing function parameter changing or tracing
function call with parameters.

Testing it:

 # perf probe tcp_sendmsg '$params'
 Added new event:
  probe:tcp_sendmsg    (on tcp_sendmsg with $params)

 You can now use it in all perf tools, such as:

	perf record -e probe:tcp_sendmsg -aR sleep 1

 # perf probe -l
  probe:tcp_sendmsg    (on tcp_sendmsg@acme/git/linux/net/ipv4/tcp.c with iocb sk msg size)
 # perf record -a -e probe:*
 press some random letters to generate TCP (sshd) traffic...

 ^C[ perf record: Woken up 1 times to write data ]
 [ perf record: Captured and wrote 0.223 MB perf.data (6 samples) ]

 # perf script
   sshd 6385 [2] 3.907529: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
   sshd 6385 [2] 4.138973: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
   sshd 6385 [2] 4.378966: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
   sshd 6385 [2] 4.603681: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
   sshd 6385 [2] 4.818455: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
   sshd 6385 [2] 5.043603: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
 # cat /sys/kernel/debug/tracing/events/probe/tcp_sendmsg/format
 name: tcp_sendmsg
 ID: 1927
 format:
   field:unsigned short common_type;	offset:0;	size:2;	signed:0;
   field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
   field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
   field:int common_pid;	offset:4;	size:4;	signed:1;

   field:unsigned long __probe_ip;	offset:8;	size:8;	signed:0;
   field:u64 iocb;	offset:16;	size:8;	signed:0;
   field:u64 sk;	offset:24;	size:8;	signed:0;
   field:u64 msg;	offset:32;	size:8;	signed:0;
   field:u64 size;	offset:40;	size:8;	signed:0;

 print fmt: "(%lx) iocb=0x%Lx sk=0x%Lx msg=0x%Lx size=0x%Lx", REC->__probe_ip, REC->iocb, REC->sk, REC->msg, REC->size
 #

 Do some system wide tracing of this probe + write syscalls:

 # perf trace -e write --ev probe:* --filter-pids 6385
  462.612 (0.010 ms): bash/19153 write(fd: 1</dev/pts/1>, buf: 0x7f7556c78000, count: 29               ) = 29
  462.701 (0.027 ms): sshd/19152 write(fd: 3<socket:[63117]>, buf: 0x7f78dd12e160, count: 68           ) ...
  462.701 (        ): probe:tcp_sendmsg:(ffffffff8163db30) iocb=0xffff8803ebec7e70 sk=0xffff88042196ab80 msg=0xffff8803ebec7da8 size=0x44)
  462.710 (0.035 ms): sshd/19152  ... [continued]: write()) = 68
  462.787 (0.009 ms): bash/19153 write(fd: 2</dev/pts/1>, buf: 0x7f7556c77000, count: 22               ) = 22
  462.865 (0.002 ms): sshd/19152 write(fd: 3<socket:[63117]>, buf: 0x7f78dd12e160, count: 68           ) ...
  462.865 (        ): probe:tcp_sendmsg:(ffffffff8163db30) iocb=0xffff8803ebec7e70 sk=0xffff88042196ab80 msg=0xffff8803ebec7da8 size=0x44)
  462.873 (0.010 ms): sshd/19152  ... [continued]: write()) = 68
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: NArnaldo 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/20150506124653.4961.59806.stgit@localhost.localdomain
[ Add some examples to the changelog message showing how to use it ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f8bffbf1
  11. 28 4月, 2015 1 次提交
    • H
      perf probe: Fix bug with global variables handling · d13855ef
      由 He Kuang 提交于 
      There are missing curly braces which causes find_variable() return wrong
value when probing with global variables.

This problem can be reproduced as following:

  $ perf probe -v --add='generic_perform_write global_variable_for_test'
  ...
  Try to find probe point from debuginfo.
  Probe point found: generic_perform_write+0
  Searching 'global_variable_for_test' variable in context.
  An error occurred in debuginfo analysis (-2).
    Error: Failed to add events. Reason: No such file or directory (Code: -2)

After this patch:

  $ perf probe -v --add='generic_perform_write global_variable_for_test'
  ...
  Converting variable global_variable_for_test into trace event.
  global_variable_for_test type is int.
  Found 1 probe_trace_events.
  Opening /sys/kernel/debug/tracing/kprobe_events write=1
  Added new event:
  Writing event: p:probe/generic_perform_write _stext+1237464
  global_variable_for_test=@global_variable_for_test+0:s32
    probe:generic_perform_write (on generic_perform_write with
    global_variable_for_test)

  You can now use it in all perf tools, such as:

      perf record -e probe:generic_perform_write -aR sleep 1
Signed-off-by: NHe Kuang <hekuang@huawei.com>
Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1429949338-18678-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d13855ef
  13. 14 4月, 2015 2 次提交
  15. 03 4月, 2015 1 次提交
  17. 07 3月, 2015 1 次提交
  19. 02 3月, 2015 1 次提交
  21. 06 2月, 2015 1 次提交
  23. 02 1月, 2015 1 次提交
    • N
      perf probe: Fix crash in dwarf_getcfi_elf · 4093325f
      由 Namhyung Kim 提交于 
      David reported that perf can segfault when adding an uprobe event like
this:

  $ perf probe -x /lib64/libc-2.14.90.so -a 'malloc  size=%di'

  (gdb) bt
  #0  parse_eh_frame_hdr (hdr=0x0, hdr_size=2596, hdr_vaddr=71788,
      ehdr=0x7fffffffd390, eh_frame_vaddr=
      0x7fffffffd378, table_entries=0x8808d8, table_encoding=0x8808e0 "") at
      dwarf_getcfi_elf.c:79
  #1  0x000000385f81615a in getcfi_scn_eh_frame (hdr_vaddr=71788,
      hdr_scn=0x8839b0, shdr=0x7fffffffd2f0, scn=<optimized out>,
      ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:231
  #2  getcfi_shdr (ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:283
  #3  dwarf_getcfi_elf (elf=0x882b30) at dwarf_getcfi_elf.c:309
  #4  0x00000000004d5bac in debuginfo__find_probes (pf=0x7fffffffd4f0,
      dbg=Unhandled dwarf expression opcode 0xfa) at util/probe-finder.c:993
  #5  0x00000000004d634a in debuginfo__find_trace_events (dbg=0x880840,
      pev=<optimized out>, tevs=0x880f88, max_tevs=<optimized out>) at
      util/probe-finder.c:1200
  #6  0x00000000004aed6b in try_to_find_probe_trace_events (target=0x881b20
      "/lib64/libpthread-2.14.90.so",
      max_tevs=128, tevs=0x880f88, pev=0x859b30) at util/probe-event.c:482
  #7  convert_to_probe_trace_events (target=0x881b20
      "/lib64/libpthread-2.14.90.so", max_tevs=128, tevs=0x880f88,
      pev=0x859b30) at util/probe-event.c:2356
  #8  add_perf_probe_events (pevs=<optimized out>, npevs=1, max_tevs=128,
      target=0x881b20 "/lib64/libpthread-2.14.90.so", force_add=false) at
      util/probe-event.c:2391
  #9  0x000000000044014f in __cmd_probe (argc=<optimized out>,
      argv=0x7fffffffe2f0, prefix=Unhandled dwarf expression opcode 0xfa) at
      at builtin-probe.c:488
  #10 0x0000000000440313 in cmd_probe (argc=5, argv=0x7fffffffe2f0,
      prefix=<optimized out>) at builtin-probe.c:506
  #11 0x000000000041d133 in run_builtin (p=0x805680, argc=5,
      argv=0x7fffffffe2f0) at perf.c:341
  #12 0x000000000041c8b2 in handle_internal_command (argv=<optimized out>,
      argc=<optimized out>) at perf.c:400
  #13 run_argv (argv=<optimized out>, argcp=<optimized out>) at perf.c:444
  #14 main (argc=5, argv=0x7fffffffe2f0) at perf.c:559

And I found a related commit (5704c8c4fa71 "getcfi_scn_eh_frame: Don't
crash and burn when .eh_frame bits aren't there.") in elfutils that can
lead to a unexpected crash like this.  To safely use the function, it
needs to check the .eh_frame section is a PROGBITS type.
Reported-by: NDavid Ahern <dsahern@gmail.com>
Tested-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Mark Wielaard <mjw@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/20141230090533.GH6081@sejongSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4093325f
  25. 18 9月, 2014 1 次提交
  27. 15 8月, 2014 1 次提交
  29. 17 7月, 2014 1 次提交
  31. 10 6月, 2014 1 次提交
    • M
      perf probe: Improve an error message of perf probe --vars mode · 69e96eaa
      由 Masami Hiramatsu 提交于 
      Fix an error message when failed to find given address in --vars
mode.

Without this fix, perf probe -V doesn't show the final "Error"
message if it fails to find given source line. Moreover, it
tells it fails to find "variables" instead of the source line.
  -----
  # perf probe -V foo@bar
  Failed to find variables at foo@bar (0)
  -----
The result also shows mysterious error code. Actually the error
returns 0 or -ENOENT means that it just fails to find the address
of given source line. (0 means there is no matching address,
and -ENOENT means there is an entry(DIE) but it has no instance,
e.g. an empty inlined function)

This fixes it to show what happened and the final error message
as below.
  -----
  # perf probe -V foo@bar
  Failed to find the address of foo@bar
    Error: Failed to show vars.
  -----
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@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/20140606071359.6788.84716.stgit@kbuild-fedora.novalocalSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      69e96eaa
  33. 09 6月, 2014 1 次提交
  35. 04 6月, 2014 1 次提交
  37. 14 4月, 2014 3 次提交
  39. 18 2月, 2014 3 次提交
  41. 28 12月, 2013 2 次提交
  43. 27 12月, 2013 1 次提交
  45. 26 12月, 2013 1 次提交
    • 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
  47. 06 11月, 2013 1 次提交
  49. 04 11月, 2013 1 次提交
  51. 23 10月, 2013 2 次提交
  53. 16 10月, 2013 1 次提交
  55. 05 10月, 2013 1 次提交
    • M
      perf probe: Fix to find line information for probe list · e08cfd4b
      由 Masami Hiramatsu 提交于 
      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: NMasami 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      e08cfd4b