kernel/tools/perf/util/dwarf-aux.c, branch linux-4.3.y

perf probe: Fix to add missed brace around if block

2015-08-13T17:51:26Z

The commit 75186a9b09e4 (perf probe: Fix to show lines of sys_ functions correctly) introduced a bug by a missed brace around if block. This fixes to add it. Signed-off-by: Masami Hiramatsu Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Fixes: 75186a9b09e4 ("perf probe: Fix to show lines of sys_ functions correctly") Link: http://lkml.kernel.org/r/20150812215541.9088.62425.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Fix to show lines of sys_ functions correctly

2015-08-12T16:20:27Z

"perf probe --lines sys_poll" shows only the first line of sys_poll, because the SYSCALL_DEFINE macro: ---- SYSCALL_DEFINE*(foo,...) { body; } ---- is expanded as below (on debuginfo) ---- static inline int SYSC_foo(...) { body; } int SyS_foo(...) <- is an alias of sys_foo. { return SYSC_foo(...); } ---- So, "perf probe --lines sys_foo" decodes SyS_foo function and it also skips inlined functions(SYSC_foo) inside the target function because those functions are usually defined somewhere else. To fix this issue, this fix checks whether the inlined function is defined at the same point of the target function, and if so, it doesn't skip the inline function. Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150812012406.11811.94691.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix dwarf-aux.c compilation on i386

2015-05-15T19:59:43Z

Replacing %lu format strings for Dwarf_Addr type with PRIu64 as it fits for Dwarf_Addr (defined as uint64_t) type and works also on both 32/64 bits. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: He Kuang Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1431706991-15646-1-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Ignore tail calls to probed functions

2015-05-14T13:05:09Z

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> <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: Naveen N. Rao Acked-by: Masami Hiramatsu Link: http://lkml.kernel.org/r/1430394151-15928-1-git-send-email-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Add --range option to show a variable's location range

2015-05-12T12:59:50Z

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(): 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 @ [INV] ssize_t written @ [INV] struct address_space_operations* a_ops @ [VAL] (unknown_type) fsdata @ [VAL] loff_t pos @ [VAL] long int status @ [VAL] long unsigned int bytes @ [VAL] struct address_space* mapping @ [VAL] struct iov_iter* i @ [VAL] struct page* page @ 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: He Kuang Acked-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1431336304-16863-2-git-send-email-hekuang@huawei.com Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Remove length limitation for showing available variables

2015-05-12T12:59:49Z

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: He Kuang Acked-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1431336304-16863-1-git-send-email-hekuang@huawei.com Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Support glob wildcards for function name

2015-05-08T19:31:02Z

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: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Ananth N Mavinakayanahalli Cc: David Ahern Cc: Hemant Kumar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20150508010335.24812.19972.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Fix to track down unnamed union/structure members

2015-04-02T16:18:44Z

Fix 'perf probe' to track down unnamed union/structure members. perf probe did not track down the tree of unnamed union/structure members, since it just failed to find given "name" in a parent structure/union. To solve this issue, I've introduced 2 changes. - Fix die_find_member() to track down the type-DIE if it is unnamed, and if it contains the specified member, returns the unnamed member. (note that we don't return found member, since unnamed member has the offset in the parent structure) - Fix convert_variable_fields() to track down the unnamed union/ structure (one-by-one). With this patch, perf probe can access unnamed fields: ----- #./perf probe -nfx ./perf lock__delete ops 'locked_ops=ops->locked.ops' Added new event: probe_perf:lock__delete (on lock__delete in /home/mhiramat/ksrc/linux-3/tools/perf/perf with ops locked_ops=ops->locked.ops) You can now use it in all perf tools, such as: perf record -e probe_perf:lock__delete -aR sleep 1 ----- Reported-by: Arnaldo Carvalho de Melo Report-Link: https://lkml.org/lkml/2015/3/5/431 Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20150402073312.14482.37942.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Fix to handle optimized not-inlined functions

2015-02-06T10:46:36Z

Fix to handle optimized no-inline functions which have only function definition but no actual instance at that point. To fix this problem, we need to find actual instance of the function. Without this patch: ---- # perf probe -a __up Failed to get entry address of __up. Error: Failed to add events. # perf probe -L __up Specified source line is not found. Error: Failed to show lines. ---- With this patch: ---- # perf probe -a __up Added new event: probe:__up (on __up) You can now use it in all perf tools, such as: perf record -e probe:__up -aR sleep 1 # perf probe -L __up <__up@/home/fedora/ksrc/linux-3/kernel/locking/semaphore.c:0> 0 static noinline void __sched __up(struct semaphore *sem) { struct semaphore_waiter *waiter = list_first_entry(&sem->wait_ struct semaphore_waite 4 list_del(&waiter->list); 5 waiter->up = true; 6 wake_up_process(waiter->task); 7 } ---- Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20150130093744.30575.43290.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Fix perf probe to find correct variable DIE

2014-06-04T12:49:20Z

Fix perf probe to find correct variable DIE which has location or external instance by tracking down the lexical blocks. Current die_find_variable() expects that the all variable DIEs which has DW_TAG_variable have a location. However, since recent dwarf information may have declaration variable DIEs at the entry of function (subprogram), die_find_variable() returns it. To solve this problem, it must track down the DIE tree to find a DIE which has an actual location or a reference for external instance. e.g. finding a DIE which origin is <0xdc73>; <1><11496>: Abbrev Number: 95 (DW_TAG_subprogram) <11497> DW_AT_abstract_origin: <0xdc42> <1149b> DW_AT_low_pc : 0x1850 [...] <2><114cc>: Abbrev Number: 119 (DW_TAG_variable) <- this is a declaration <114cd> DW_AT_abstract_origin: <0xdc73> <2><114d1>: Abbrev Number: 119 (DW_TAG_variable) [...] <3><115a7>: Abbrev Number: 105 (DW_TAG_lexical_block) <115a8> DW_AT_ranges : 0xaa0 <4><115ac>: Abbrev Number: 96 (DW_TAG_variable) <- this has a location <115ad> DW_AT_abstract_origin: <0xdc73> <115b1> DW_AT_location : 0x486c (location list) Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Acked-by: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20140529121930.30879.87092.stgit@ltc230.yrl.intra.hitachi.co.jp Signed-off-by: Jiri Olsa