OpenCloudOS-Kernel/tools/perf/util/dwarf-aux.c

1294 lines
33 KiB
C
Raw Normal View History

/*
* dwarf-aux.c : libdw auxiliary interfaces
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
*/
#include <errno.h>
#include <inttypes.h>
#include <stdbool.h>
#include "util.h"
#include "debug.h"
#include "dwarf-aux.h"
#include "string2.h"
/**
* cu_find_realpath - Find the realpath of the target file
* @cu_die: A DIE(dwarf information entry) of CU(compilation Unit)
* @fname: The tail filename of the target file
*
* Find the real(long) path of @fname in @cu_die.
*/
const char *cu_find_realpath(Dwarf_Die *cu_die, const char *fname)
{
Dwarf_Files *files;
size_t nfiles, i;
const char *src = NULL;
int ret;
if (!fname)
return NULL;
ret = dwarf_getsrcfiles(cu_die, &files, &nfiles);
if (ret != 0)
return NULL;
for (i = 0; i < nfiles; i++) {
src = dwarf_filesrc(files, i, NULL, NULL);
if (strtailcmp(src, fname) == 0)
break;
}
if (i == nfiles)
return NULL;
return src;
}
/**
* cu_get_comp_dir - Get the path of compilation directory
* @cu_die: a CU DIE
*
* Get the path of compilation directory of given @cu_die.
* Since this depends on DW_AT_comp_dir, older gcc will not
* embedded it. In that case, this returns NULL.
*/
const char *cu_get_comp_dir(Dwarf_Die *cu_die)
{
Dwarf_Attribute attr;
if (dwarf_attr(cu_die, DW_AT_comp_dir, &attr) == NULL)
return NULL;
return dwarf_formstring(&attr);
}
/**
* cu_find_lineinfo - Get a line number and file name for given address
* @cu_die: a CU DIE
* @addr: An address
* @fname: a pointer which returns the file name string
* @lineno: a pointer which returns the line number
*
* Find a line number and file name for @addr in @cu_die.
*/
int cu_find_lineinfo(Dwarf_Die *cu_die, unsigned long addr,
const char **fname, int *lineno)
{
Dwarf_Line *line;
Dwarf_Addr laddr;
line = dwarf_getsrc_die(cu_die, (Dwarf_Addr)addr);
if (line && dwarf_lineaddr(line, &laddr) == 0 &&
addr == (unsigned long)laddr && dwarf_lineno(line, lineno) == 0) {
*fname = dwarf_linesrc(line, NULL, NULL);
if (!*fname)
/* line number is useless without filename */
*lineno = 0;
}
return *lineno ?: -ENOENT;
}
static int __die_find_inline_cb(Dwarf_Die *die_mem, void *data);
/**
* cu_walk_functions_at - Walk on function DIEs at given address
* @cu_die: A CU DIE
* @addr: An address
* @callback: A callback which called with found DIEs
* @data: A user data
*
* Walk on function DIEs at given @addr in @cu_die. Passed DIEs
* should be subprogram or inlined-subroutines.
*/
int cu_walk_functions_at(Dwarf_Die *cu_die, Dwarf_Addr addr,
int (*callback)(Dwarf_Die *, void *), void *data)
{
Dwarf_Die die_mem;
Dwarf_Die *sc_die;
int ret = -ENOENT;
/* Inlined function could be recursive. Trace it until fail */
for (sc_die = die_find_realfunc(cu_die, addr, &die_mem);
sc_die != NULL;
sc_die = die_find_child(sc_die, __die_find_inline_cb, &addr,
&die_mem)) {
ret = callback(sc_die, data);
if (ret)
break;
}
return ret;
}
perf probe: Match linkage name with mangled name Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows 'perf probe' to find appropriate probe point from mangled symbol as below. E.g. without this fix: ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Probe point '_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv' not found. Error: Failed to add events. ---- With this fix, perf probe can find the correct one. ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv p:probe_libstdc/_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv /usr/lib64/libstdc++.so.6.0.22:0x8ca60 ---- Committer notes: After the fix, setting it for real (no -D/--definition, that amounts to a --dry-run): # perf probe -x /usr/lib64/libstdc++.so.6 _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Added new event: probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv in /usr/lib64/libstdc++.so.6.0.22) You can now use it in all perf tools, such as: perf record -e probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv -aR sleep 1 # perf probe -l probe_libstdc:* probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on is_open@libstdc++-v3/include/fstream in /usr/lib64/libstdc++.so.6.0.22) # Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/147464493162.29804.16715053505069382443.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-09-23 23:35:31 +08:00
/**
* die_get_linkage_name - Get the linkage name of the object
* @dw_die: A DIE of the object
*
* Get the linkage name attiribute of given @dw_die.
* For C++ binary, the linkage name will be the mangled symbol.
*/
const char *die_get_linkage_name(Dwarf_Die *dw_die)
{
Dwarf_Attribute attr;
if (dwarf_attr_integrate(dw_die, DW_AT_linkage_name, &attr) == NULL)
return NULL;
return dwarf_formstring(&attr);
}
/**
* die_compare_name - Compare diename and tname
* @dw_die: a DIE
* @tname: a string of target name
*
* Compare the name of @dw_die and @tname. Return false if @dw_die has no name.
*/
bool die_compare_name(Dwarf_Die *dw_die, const char *tname)
{
const char *name;
name = dwarf_diename(dw_die);
return name ? (strcmp(tname, name) == 0) : false;
}
/**
perf probe: Match linkage name with mangled name Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows 'perf probe' to find appropriate probe point from mangled symbol as below. E.g. without this fix: ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Probe point '_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv' not found. Error: Failed to add events. ---- With this fix, perf probe can find the correct one. ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv p:probe_libstdc/_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv /usr/lib64/libstdc++.so.6.0.22:0x8ca60 ---- Committer notes: After the fix, setting it for real (no -D/--definition, that amounts to a --dry-run): # perf probe -x /usr/lib64/libstdc++.so.6 _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Added new event: probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv in /usr/lib64/libstdc++.so.6.0.22) You can now use it in all perf tools, such as: perf record -e probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv -aR sleep 1 # perf probe -l probe_libstdc:* probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on is_open@libstdc++-v3/include/fstream in /usr/lib64/libstdc++.so.6.0.22) # Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/147464493162.29804.16715053505069382443.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-09-23 23:35:31 +08:00
* die_match_name - Match diename/linkage name and glob
* @dw_die: a DIE
* @glob: a string of target glob pattern
*
* Glob matching the name of @dw_die and @glob. Return false if matching fail.
perf probe: Match linkage name with mangled name Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows 'perf probe' to find appropriate probe point from mangled symbol as below. E.g. without this fix: ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Probe point '_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv' not found. Error: Failed to add events. ---- With this fix, perf probe can find the correct one. ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv p:probe_libstdc/_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv /usr/lib64/libstdc++.so.6.0.22:0x8ca60 ---- Committer notes: After the fix, setting it for real (no -D/--definition, that amounts to a --dry-run): # perf probe -x /usr/lib64/libstdc++.so.6 _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Added new event: probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv in /usr/lib64/libstdc++.so.6.0.22) You can now use it in all perf tools, such as: perf record -e probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv -aR sleep 1 # perf probe -l probe_libstdc:* probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on is_open@libstdc++-v3/include/fstream in /usr/lib64/libstdc++.so.6.0.22) # Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/147464493162.29804.16715053505069382443.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-09-23 23:35:31 +08:00
* This also match linkage name.
*/
bool die_match_name(Dwarf_Die *dw_die, const char *glob)
{
const char *name;
name = dwarf_diename(dw_die);
perf probe: Match linkage name with mangled name Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows 'perf probe' to find appropriate probe point from mangled symbol as below. E.g. without this fix: ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Probe point '_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv' not found. Error: Failed to add events. ---- With this fix, perf probe can find the correct one. ---- $ perf probe -x /usr/lib64/libstdc++.so.6 \ -D _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv p:probe_libstdc/_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv /usr/lib64/libstdc++.so.6.0.22:0x8ca60 ---- Committer notes: After the fix, setting it for real (no -D/--definition, that amounts to a --dry-run): # perf probe -x /usr/lib64/libstdc++.so.6 _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv Added new event: probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on _ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv in /usr/lib64/libstdc++.so.6.0.22) You can now use it in all perf tools, such as: perf record -e probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv -aR sleep 1 # perf probe -l probe_libstdc:* probe_libstdc:_ZNKSt15basic_fstreamXXIwSt11char_traitsIwEE7is_openEv (on is_open@libstdc++-v3/include/fstream in /usr/lib64/libstdc++.so.6.0.22) # Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/147464493162.29804.16715053505069382443.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-09-23 23:35:31 +08:00
if (name && strglobmatch(name, glob))
return true;
/* fall back to check linkage name */
name = die_get_linkage_name(dw_die);
if (name && strglobmatch(name, glob))
return true;
return false;
}
/**
* die_get_call_lineno - Get callsite line number of inline-function instance
* @in_die: a DIE of an inlined function instance
*
* Get call-site line number of @in_die. This means from where the inline
* function is called.
*/
int die_get_call_lineno(Dwarf_Die *in_die)
{
Dwarf_Attribute attr;
Dwarf_Word ret;
if (!dwarf_attr(in_die, DW_AT_call_line, &attr))
return -ENOENT;
dwarf_formudata(&attr, &ret);
return (int)ret;
}
/**
* die_get_type - Get type DIE
* @vr_die: a DIE of a variable
* @die_mem: where to store a type DIE
*
* Get a DIE of the type of given variable (@vr_die), and store
* it to die_mem. Return NULL if fails to get a type DIE.
*/
Dwarf_Die *die_get_type(Dwarf_Die *vr_die, Dwarf_Die *die_mem)
{
Dwarf_Attribute attr;
if (dwarf_attr_integrate(vr_die, DW_AT_type, &attr) &&
dwarf_formref_die(&attr, die_mem))
return die_mem;
else
return NULL;
}
/* Get a type die, but skip qualifiers */
static Dwarf_Die *__die_get_real_type(Dwarf_Die *vr_die, Dwarf_Die *die_mem)
{
int tag;
do {
vr_die = die_get_type(vr_die, die_mem);
if (!vr_die)
break;
tag = dwarf_tag(vr_die);
} while (tag == DW_TAG_const_type ||
tag == DW_TAG_restrict_type ||
tag == DW_TAG_volatile_type ||
tag == DW_TAG_shared_type);
return vr_die;
}
/**
* die_get_real_type - Get a type die, but skip qualifiers and typedef
* @vr_die: a DIE of a variable
* @die_mem: where to store a type DIE
*
* Get a DIE of the type of given variable (@vr_die), and store
* it to die_mem. Return NULL if fails to get a type DIE.
* If the type is qualifiers (e.g. const) or typedef, this skips it
* and tries to find real type (structure or basic types, e.g. int).
*/
Dwarf_Die *die_get_real_type(Dwarf_Die *vr_die, Dwarf_Die *die_mem)
{
do {
vr_die = __die_get_real_type(vr_die, die_mem);
} while (vr_die && dwarf_tag(vr_die) == DW_TAG_typedef);
return vr_die;
}
/* Get attribute and translate it as a udata */
static int die_get_attr_udata(Dwarf_Die *tp_die, unsigned int attr_name,
Dwarf_Word *result)
{
Dwarf_Attribute attr;
if (dwarf_attr(tp_die, attr_name, &attr) == NULL ||
dwarf_formudata(&attr, result) != 0)
return -ENOENT;
return 0;
}
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
/* Get attribute and translate it as a sdata */
static int die_get_attr_sdata(Dwarf_Die *tp_die, unsigned int attr_name,
Dwarf_Sword *result)
{
Dwarf_Attribute attr;
if (dwarf_attr(tp_die, attr_name, &attr) == NULL ||
dwarf_formsdata(&attr, result) != 0)
return -ENOENT;
return 0;
}
/**
* die_is_signed_type - Check whether a type DIE is signed or not
* @tp_die: a DIE of a type
*
* Get the encoding of @tp_die and return true if the encoding
* is signed.
*/
bool die_is_signed_type(Dwarf_Die *tp_die)
{
Dwarf_Word ret;
if (die_get_attr_udata(tp_die, DW_AT_encoding, &ret))
return false;
return (ret == DW_ATE_signed_char || ret == DW_ATE_signed ||
ret == DW_ATE_signed_fixed);
}
/**
* die_is_func_def - Ensure that this DIE is a subprogram and definition
* @dw_die: a DIE
*
* Ensure that this DIE is a subprogram and NOT a declaration. This
* returns true if @dw_die is a function definition.
**/
bool die_is_func_def(Dwarf_Die *dw_die)
{
Dwarf_Attribute attr;
return (dwarf_tag(dw_die) == DW_TAG_subprogram &&
dwarf_attr(dw_die, DW_AT_declaration, &attr) == NULL);
}
/**
* die_is_func_instance - Ensure that this DIE is an instance of a subprogram
* @dw_die: a DIE
*
* Ensure that this DIE is an instance (which has an entry address).
* This returns true if @dw_die is a function instance. If not, you need to
* call die_walk_instances() to find actual instances.
**/
bool die_is_func_instance(Dwarf_Die *dw_die)
{
Dwarf_Addr tmp;
/* Actually gcc optimizes non-inline as like as inlined */
return !dwarf_func_inline(dw_die) && dwarf_entrypc(dw_die, &tmp) == 0;
}
/**
* die_get_data_member_location - Get the data-member offset
* @mb_die: a DIE of a member of a data structure
* @offs: The offset of the member in the data structure
*
* Get the offset of @mb_die in the data structure including @mb_die, and
* stores result offset to @offs. If any error occurs this returns errno.
*/
int die_get_data_member_location(Dwarf_Die *mb_die, Dwarf_Word *offs)
{
Dwarf_Attribute attr;
Dwarf_Op *expr;
size_t nexpr;
int ret;
if (dwarf_attr(mb_die, DW_AT_data_member_location, &attr) == NULL)
return -ENOENT;
if (dwarf_formudata(&attr, offs) != 0) {
/* DW_AT_data_member_location should be DW_OP_plus_uconst */
ret = dwarf_getlocation(&attr, &expr, &nexpr);
if (ret < 0 || nexpr == 0)
return -ENOENT;
if (expr[0].atom != DW_OP_plus_uconst || nexpr != 1) {
pr_debug("Unable to get offset:Unexpected OP %x (%zd)\n",
expr[0].atom, nexpr);
return -ENOTSUP;
}
*offs = (Dwarf_Word)expr[0].number;
}
return 0;
}
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
/* Get the call file index number in CU DIE */
static int die_get_call_fileno(Dwarf_Die *in_die)
{
Dwarf_Sword idx;
if (die_get_attr_sdata(in_die, DW_AT_call_file, &idx) == 0)
return (int)idx;
else
return -ENOENT;
}
perf probe: Filter out redundant inline-instances With gcc4.6, some instances of concrete inlined function looks redundant and broken, because it appears inside of a concrete instance and its call_file and call_line are same as the original abstruct's decl_file and decl_line respectively. e.g. [ d1aa] subprogram external (flag) Yes name (strp) "add_timer" decl_file (data1) 2 ;here is original decl_line (data2) 847 ;line and file prototyped (flag) Yes inline (data1) inlined (1) sibling (ref4) [ d1c6] ... [ 11d84] subprogram abstract_origin (ref4) [ d1aa] ; concrete instance low_pc (addr) .text+0x000000000000246f <add_timer> high_pc (addr) .text+0x000000000000248b <mod_timer_pending> frame_base (block1) [ 0] call_frame_cfa sibling (ref4) [ 11dd9] [ 11d9f] formal_parameter abstract_origin (ref4) [ d1b9] location (data4) location list [ 701b] [ 11da8] inlined_subroutine abstract_origin (ref4) [ d1aa] ; redundant instance low_pc (addr) .text+0x000000000000247e <add_timer+0xf> high_pc (addr) .text+0x0000000000002480 <add_timer+0x11> call_file (data1) 2 ; call line and file call_line (data2) 847 ; are same as above Those redundant instances leads unwilling results; e.g. find probe points inside of functions even if we specify a function entry as below; $ perf probe -V add_timer Available variables at add_timer @<add_timer+0> struct timer_list* timer @<add_timer+15> (No matched variables) So, this filters out those redundant instances based on call-site and decl-site information. 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/20110811110317.19900.59525.stgit@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:03:18 +08:00
/* Get the declared file index number in CU DIE */
static int die_get_decl_fileno(Dwarf_Die *pdie)
{
Dwarf_Sword idx;
if (die_get_attr_sdata(pdie, DW_AT_decl_file, &idx) == 0)
return (int)idx;
else
return -ENOENT;
}
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
/**
* die_get_call_file - Get callsite file name of inlined function instance
* @in_die: a DIE of an inlined function instance
*
* Get call-site file name of @in_die. This means from which file the inline
* function is called.
*/
const char *die_get_call_file(Dwarf_Die *in_die)
{
Dwarf_Die cu_die;
Dwarf_Files *files;
int idx;
idx = die_get_call_fileno(in_die);
if (idx < 0 || !dwarf_diecu(in_die, &cu_die, NULL, NULL) ||
dwarf_getsrcfiles(&cu_die, &files, NULL) != 0)
return NULL;
return dwarf_filesrc(files, idx, NULL, NULL);
}
/**
* die_find_child - Generic DIE search function in DIE tree
* @rt_die: a root DIE
* @callback: a callback function
* @data: a user data passed to the callback function
* @die_mem: a buffer for result DIE
*
* Trace DIE tree from @rt_die and call @callback for each child DIE.
* If @callback returns DIE_FIND_CB_END, this stores the DIE into
* @die_mem and returns it. If @callback returns DIE_FIND_CB_CONTINUE,
* this continues to trace the tree. Optionally, @callback can return
* DIE_FIND_CB_CHILD and DIE_FIND_CB_SIBLING, those means trace only
* the children and trace only the siblings respectively.
* Returns NULL if @callback can't find any appropriate DIE.
*/
Dwarf_Die *die_find_child(Dwarf_Die *rt_die,
int (*callback)(Dwarf_Die *, void *),
void *data, Dwarf_Die *die_mem)
{
Dwarf_Die child_die;
int ret;
ret = dwarf_child(rt_die, die_mem);
if (ret != 0)
return NULL;
do {
ret = callback(die_mem, data);
if (ret == DIE_FIND_CB_END)
return die_mem;
if ((ret & DIE_FIND_CB_CHILD) &&
die_find_child(die_mem, callback, data, &child_die)) {
memcpy(die_mem, &child_die, sizeof(Dwarf_Die));
return die_mem;
}
} while ((ret & DIE_FIND_CB_SIBLING) &&
dwarf_siblingof(die_mem, die_mem) == 0);
return NULL;
}
struct __addr_die_search_param {
Dwarf_Addr addr;
Dwarf_Die *die_mem;
};
perf probe: Ignore tail calls to probed functions 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: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> 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 <acme@redhat.com>
2015-04-30 19:42:31 +08:00
static int __die_search_func_tail_cb(Dwarf_Die *fn_die, void *data)
{
struct __addr_die_search_param *ad = data;
Dwarf_Addr addr = 0;
if (dwarf_tag(fn_die) == DW_TAG_subprogram &&
!dwarf_highpc(fn_die, &addr) &&
addr == ad->addr) {
memcpy(ad->die_mem, fn_die, sizeof(Dwarf_Die));
return DWARF_CB_ABORT;
}
return DWARF_CB_OK;
}
/**
* die_find_tailfunc - Search for a non-inlined function with tail call at
* given address
* @cu_die: a CU DIE which including @addr
* @addr: target address
* @die_mem: a buffer for result DIE
*
* Search for a non-inlined function DIE with tail call at @addr. Stores the
* DIE to @die_mem and returns it if found. Returns NULL if failed.
*/
Dwarf_Die *die_find_tailfunc(Dwarf_Die *cu_die, Dwarf_Addr addr,
Dwarf_Die *die_mem)
{
struct __addr_die_search_param ad;
ad.addr = addr;
ad.die_mem = die_mem;
/* dwarf_getscopes can't find subprogram. */
if (!dwarf_getfuncs(cu_die, __die_search_func_tail_cb, &ad, 0))
return NULL;
else
return die_mem;
}
/* die_find callback for non-inlined function search */
static int __die_search_func_cb(Dwarf_Die *fn_die, void *data)
{
struct __addr_die_search_param *ad = data;
/*
* Since a declaration entry doesn't has given pc, this always returns
* function definition entry.
*/
if (dwarf_tag(fn_die) == DW_TAG_subprogram &&
dwarf_haspc(fn_die, ad->addr)) {
memcpy(ad->die_mem, fn_die, sizeof(Dwarf_Die));
return DWARF_CB_ABORT;
}
return DWARF_CB_OK;
}
/**
* die_find_realfunc - Search a non-inlined function at given address
* @cu_die: a CU DIE which including @addr
* @addr: target address
* @die_mem: a buffer for result DIE
*
* Search a non-inlined function DIE which includes @addr. Stores the
perf probe: Fix to find line information for probe list 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: Masami 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.jp Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2013-09-30 17:21:44 +08:00
* DIE to @die_mem and returns it if found. Returns NULL if failed.
*/
Dwarf_Die *die_find_realfunc(Dwarf_Die *cu_die, Dwarf_Addr addr,
Dwarf_Die *die_mem)
{
struct __addr_die_search_param ad;
ad.addr = addr;
ad.die_mem = die_mem;
/* dwarf_getscopes can't find subprogram. */
if (!dwarf_getfuncs(cu_die, __die_search_func_cb, &ad, 0))
return NULL;
else
return die_mem;
}
/* die_find callback for inline function search */
static int __die_find_inline_cb(Dwarf_Die *die_mem, void *data)
{
Dwarf_Addr *addr = data;
if (dwarf_tag(die_mem) == DW_TAG_inlined_subroutine &&
dwarf_haspc(die_mem, *addr))
return DIE_FIND_CB_END;
return DIE_FIND_CB_CONTINUE;
}
perf probe: Fix to find line information for probe list 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: Masami 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.jp Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2013-09-30 17:21:44 +08:00
/**
* die_find_top_inlinefunc - Search the top inlined function at given address
* @sp_die: a subprogram DIE which including @addr
* @addr: target address
* @die_mem: a buffer for result DIE
*
* Search an inlined function DIE which includes @addr. Stores the
* DIE to @die_mem and returns it if found. Returns NULL if failed.
* Even if several inlined functions are expanded recursively, this
* doesn't trace it down, and returns the topmost one.
*/
Dwarf_Die *die_find_top_inlinefunc(Dwarf_Die *sp_die, Dwarf_Addr addr,
Dwarf_Die *die_mem)
{
return die_find_child(sp_die, __die_find_inline_cb, &addr, die_mem);
}
/**
* die_find_inlinefunc - Search an inlined function at given address
perf probe: Fix to find line information for probe list 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: Masami 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.jp Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2013-09-30 17:21:44 +08:00
* @sp_die: a subprogram DIE which including @addr
* @addr: target address
* @die_mem: a buffer for result DIE
*
* Search an inlined function DIE which includes @addr. Stores the
perf probe: Fix to find line information for probe list 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: Masami 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.jp Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2013-09-30 17:21:44 +08:00
* DIE to @die_mem and returns it if found. Returns NULL if failed.
* If several inlined functions are expanded recursively, this trace
perf probe: Fix to find line information for probe list 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: Masami 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.jp Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2013-09-30 17:21:44 +08:00
* it down and returns deepest one.
*/
Dwarf_Die *die_find_inlinefunc(Dwarf_Die *sp_die, Dwarf_Addr addr,
Dwarf_Die *die_mem)
{
Dwarf_Die tmp_die;
sp_die = die_find_child(sp_die, __die_find_inline_cb, &addr, &tmp_die);
if (!sp_die)
return NULL;
/* Inlined function could be recursive. Trace it until fail */
while (sp_die) {
memcpy(die_mem, sp_die, sizeof(Dwarf_Die));
sp_die = die_find_child(sp_die, __die_find_inline_cb, &addr,
&tmp_die);
}
return die_mem;
}
struct __instance_walk_param {
void *addr;
int (*callback)(Dwarf_Die *, void *);
void *data;
int retval;
};
static int __die_walk_instances_cb(Dwarf_Die *inst, void *data)
{
struct __instance_walk_param *iwp = data;
Dwarf_Attribute attr_mem;
Dwarf_Die origin_mem;
Dwarf_Attribute *attr;
Dwarf_Die *origin;
perf probe: Filter out redundant inline-instances With gcc4.6, some instances of concrete inlined function looks redundant and broken, because it appears inside of a concrete instance and its call_file and call_line are same as the original abstruct's decl_file and decl_line respectively. e.g. [ d1aa] subprogram external (flag) Yes name (strp) "add_timer" decl_file (data1) 2 ;here is original decl_line (data2) 847 ;line and file prototyped (flag) Yes inline (data1) inlined (1) sibling (ref4) [ d1c6] ... [ 11d84] subprogram abstract_origin (ref4) [ d1aa] ; concrete instance low_pc (addr) .text+0x000000000000246f <add_timer> high_pc (addr) .text+0x000000000000248b <mod_timer_pending> frame_base (block1) [ 0] call_frame_cfa sibling (ref4) [ 11dd9] [ 11d9f] formal_parameter abstract_origin (ref4) [ d1b9] location (data4) location list [ 701b] [ 11da8] inlined_subroutine abstract_origin (ref4) [ d1aa] ; redundant instance low_pc (addr) .text+0x000000000000247e <add_timer+0xf> high_pc (addr) .text+0x0000000000002480 <add_timer+0x11> call_file (data1) 2 ; call line and file call_line (data2) 847 ; are same as above Those redundant instances leads unwilling results; e.g. find probe points inside of functions even if we specify a function entry as below; $ perf probe -V add_timer Available variables at add_timer @<add_timer+0> struct timer_list* timer @<add_timer+15> (No matched variables) So, this filters out those redundant instances based on call-site and decl-site information. 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/20110811110317.19900.59525.stgit@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:03:18 +08:00
int tmp;
attr = dwarf_attr(inst, DW_AT_abstract_origin, &attr_mem);
if (attr == NULL)
return DIE_FIND_CB_CONTINUE;
origin = dwarf_formref_die(attr, &origin_mem);
if (origin == NULL || origin->addr != iwp->addr)
return DIE_FIND_CB_CONTINUE;
perf probe: Filter out redundant inline-instances With gcc4.6, some instances of concrete inlined function looks redundant and broken, because it appears inside of a concrete instance and its call_file and call_line are same as the original abstruct's decl_file and decl_line respectively. e.g. [ d1aa] subprogram external (flag) Yes name (strp) "add_timer" decl_file (data1) 2 ;here is original decl_line (data2) 847 ;line and file prototyped (flag) Yes inline (data1) inlined (1) sibling (ref4) [ d1c6] ... [ 11d84] subprogram abstract_origin (ref4) [ d1aa] ; concrete instance low_pc (addr) .text+0x000000000000246f <add_timer> high_pc (addr) .text+0x000000000000248b <mod_timer_pending> frame_base (block1) [ 0] call_frame_cfa sibling (ref4) [ 11dd9] [ 11d9f] formal_parameter abstract_origin (ref4) [ d1b9] location (data4) location list [ 701b] [ 11da8] inlined_subroutine abstract_origin (ref4) [ d1aa] ; redundant instance low_pc (addr) .text+0x000000000000247e <add_timer+0xf> high_pc (addr) .text+0x0000000000002480 <add_timer+0x11> call_file (data1) 2 ; call line and file call_line (data2) 847 ; are same as above Those redundant instances leads unwilling results; e.g. find probe points inside of functions even if we specify a function entry as below; $ perf probe -V add_timer Available variables at add_timer @<add_timer+0> struct timer_list* timer @<add_timer+15> (No matched variables) So, this filters out those redundant instances based on call-site and decl-site information. 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/20110811110317.19900.59525.stgit@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:03:18 +08:00
/* Ignore redundant instances */
if (dwarf_tag(inst) == DW_TAG_inlined_subroutine) {
dwarf_decl_line(origin, &tmp);
if (die_get_call_lineno(inst) == tmp) {
tmp = die_get_decl_fileno(origin);
if (die_get_call_fileno(inst) == tmp)
return DIE_FIND_CB_CONTINUE;
}
}
iwp->retval = iwp->callback(inst, iwp->data);
return (iwp->retval) ? DIE_FIND_CB_END : DIE_FIND_CB_CONTINUE;
}
/**
* die_walk_instances - Walk on instances of given DIE
* @or_die: an abstract original DIE
* @callback: a callback function which is called with instance DIE
* @data: user data
*
* Walk on the instances of give @in_die. @in_die must be an inlined function
* declartion. This returns the return value of @callback if it returns
* non-zero value, or -ENOENT if there is no instance.
*/
int die_walk_instances(Dwarf_Die *or_die, int (*callback)(Dwarf_Die *, void *),
void *data)
{
Dwarf_Die cu_die;
Dwarf_Die die_mem;
struct __instance_walk_param iwp = {
.addr = or_die->addr,
.callback = callback,
.data = data,
.retval = -ENOENT,
};
if (dwarf_diecu(or_die, &cu_die, NULL, NULL) == NULL)
return -ENOENT;
die_find_child(&cu_die, __die_walk_instances_cb, &iwp, &die_mem);
return iwp.retval;
}
/* Line walker internal parameters */
struct __line_walk_param {
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
bool recursive;
line_walk_callback_t callback;
void *data;
int retval;
};
static int __die_walk_funclines_cb(Dwarf_Die *in_die, void *data)
{
struct __line_walk_param *lw = data;
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
Dwarf_Addr addr = 0;
const char *fname;
int lineno;
if (dwarf_tag(in_die) == DW_TAG_inlined_subroutine) {
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
fname = die_get_call_file(in_die);
lineno = die_get_call_lineno(in_die);
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
if (fname && lineno > 0 && dwarf_entrypc(in_die, &addr) == 0) {
lw->retval = lw->callback(fname, lineno, addr, lw->data);
if (lw->retval != 0)
return DIE_FIND_CB_END;
}
}
if (!lw->recursive)
/* Don't need to search recursively */
return DIE_FIND_CB_SIBLING;
if (addr) {
fname = dwarf_decl_file(in_die);
if (fname && dwarf_decl_line(in_die, &lineno) == 0) {
lw->retval = lw->callback(fname, lineno, addr, lw->data);
if (lw->retval != 0)
return DIE_FIND_CB_END;
}
}
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
/* Continue to search nested inlined function call-sites */
return DIE_FIND_CB_CONTINUE;
}
/* Walk on lines of blocks included in given DIE */
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
static int __die_walk_funclines(Dwarf_Die *sp_die, bool recursive,
line_walk_callback_t callback, void *data)
{
struct __line_walk_param lw = {
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
.recursive = recursive,
.callback = callback,
.data = data,
.retval = 0,
};
Dwarf_Die die_mem;
Dwarf_Addr addr;
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
const char *fname;
int lineno;
/* Handle function declaration line */
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
fname = dwarf_decl_file(sp_die);
if (fname && dwarf_decl_line(sp_die, &lineno) == 0 &&
dwarf_entrypc(sp_die, &addr) == 0) {
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
lw.retval = callback(fname, lineno, addr, data);
if (lw.retval != 0)
goto done;
}
die_find_child(sp_die, __die_walk_funclines_cb, &lw, &die_mem);
done:
return lw.retval;
}
static int __die_walk_culines_cb(Dwarf_Die *sp_die, void *data)
{
struct __line_walk_param *lw = data;
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
lw->retval = __die_walk_funclines(sp_die, true, lw->callback, lw->data);
if (lw->retval != 0)
return DWARF_CB_ABORT;
return DWARF_CB_OK;
}
/**
* die_walk_lines - Walk on lines inside given DIE
* @rt_die: a root DIE (CU, subprogram or inlined_subroutine)
* @callback: callback routine
* @data: user data
*
* Walk on all lines inside given @rt_die and call @callback on each line.
* If the @rt_die is a function, walk only on the lines inside the function,
* otherwise @rt_die must be a CU DIE.
* Note that this walks not only dwarf line list, but also function entries
* and inline call-site.
*/
int die_walk_lines(Dwarf_Die *rt_die, line_walk_callback_t callback, void *data)
{
Dwarf_Lines *lines;
Dwarf_Line *line;
Dwarf_Addr addr;
const char *fname, *decf = NULL;
int lineno, ret = 0;
int decl = 0, inl;
Dwarf_Die die_mem, *cu_die;
size_t nlines, i;
/* Get the CU die */
if (dwarf_tag(rt_die) != DW_TAG_compile_unit) {
cu_die = dwarf_diecu(rt_die, &die_mem, NULL, NULL);
dwarf_decl_line(rt_die, &decl);
decf = dwarf_decl_file(rt_die);
} else
cu_die = rt_die;
if (!cu_die) {
pr_debug2("Failed to get CU from given DIE.\n");
return -EINVAL;
}
/* Get lines list in the CU */
if (dwarf_getsrclines(cu_die, &lines, &nlines) != 0) {
pr_debug2("Failed to get source lines on this CU.\n");
return -ENOENT;
}
pr_debug2("Get %zd lines from this CU\n", nlines);
/* Walk on the lines on lines list */
for (i = 0; i < nlines; i++) {
line = dwarf_onesrcline(lines, i);
if (line == NULL ||
dwarf_lineno(line, &lineno) != 0 ||
dwarf_lineaddr(line, &addr) != 0) {
pr_debug2("Failed to get line info. "
"Possible error in debuginfo.\n");
continue;
}
/* Filter lines based on address */
if (rt_die != cu_die) {
/*
* Address filtering
* The line is included in given function, and
* no inline block includes it.
*/
if (!dwarf_haspc(rt_die, addr))
continue;
if (die_find_inlinefunc(rt_die, addr, &die_mem)) {
dwarf_decl_line(&die_mem, &inl);
if (inl != decl ||
decf != dwarf_decl_file(&die_mem))
continue;
}
}
/* Get source line */
fname = dwarf_linesrc(line, NULL, NULL);
ret = callback(fname, lineno, addr, data);
if (ret != 0)
return ret;
}
/*
* Dwarf lines doesn't include function declarations and inlined
* subroutines. We have to check functions list or given function.
*/
if (rt_die != cu_die)
perf probe: Fix to search nested inlined functions in CU 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@fedora15 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-08-11 19:02:41 +08:00
/*
* Don't need walk functions recursively, because nested
* inlined functions don't have lines of the specified DIE.
*/
ret = __die_walk_funclines(rt_die, false, callback, data);
else {
struct __line_walk_param param = {
.callback = callback,
.data = data,
.retval = 0,
};
dwarf_getfuncs(cu_die, __die_walk_culines_cb, &param, 0);
ret = param.retval;
}
return ret;
}
struct __find_variable_param {
const char *name;
Dwarf_Addr addr;
};
static int __die_find_variable_cb(Dwarf_Die *die_mem, void *data)
{
struct __find_variable_param *fvp = data;
perf probe: Fix perf probe to find correct variable DIE 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 <masami.hiramatsu.pt@hitachi.com> Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/20140529121930.30879.87092.stgit@ltc230.yrl.intra.hitachi.co.jp Signed-off-by: Jiri Olsa <jolsa@kernel.org>
2014-05-29 20:19:30 +08:00
Dwarf_Attribute attr;
int tag;
tag = dwarf_tag(die_mem);
if ((tag == DW_TAG_formal_parameter ||
tag == DW_TAG_variable) &&
perf probe: Fix perf probe to find correct variable DIE 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 <masami.hiramatsu.pt@hitachi.com> Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/20140529121930.30879.87092.stgit@ltc230.yrl.intra.hitachi.co.jp Signed-off-by: Jiri Olsa <jolsa@kernel.org>
2014-05-29 20:19:30 +08:00
die_compare_name(die_mem, fvp->name) &&
/* Does the DIE have location information or external instance? */
(dwarf_attr(die_mem, DW_AT_external, &attr) ||
dwarf_attr(die_mem, DW_AT_location, &attr)))
return DIE_FIND_CB_END;
if (dwarf_haspc(die_mem, fvp->addr))
return DIE_FIND_CB_CONTINUE;
else
return DIE_FIND_CB_SIBLING;
}
/**
* die_find_variable_at - Find a given name variable at given address
* @sp_die: a function DIE
* @name: variable name
* @addr: address
* @die_mem: a buffer for result DIE
*
* Find a variable DIE called @name at @addr in @sp_die.
*/
Dwarf_Die *die_find_variable_at(Dwarf_Die *sp_die, const char *name,
Dwarf_Addr addr, Dwarf_Die *die_mem)
{
struct __find_variable_param fvp = { .name = name, .addr = addr};
return die_find_child(sp_die, __die_find_variable_cb, (void *)&fvp,
die_mem);
}
static int __die_find_member_cb(Dwarf_Die *die_mem, void *data)
{
const char *name = data;
perf probe: Fix to track down unnamed union/structure members 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 <acme@kernel.org> Report-Link: https://lkml.org/lkml/2015/3/5/431 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.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/20150402073312.14482.37942.stgit@localhost.localdomain Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-04-02 15:33:12 +08:00
if (dwarf_tag(die_mem) == DW_TAG_member) {
if (die_compare_name(die_mem, name))
return DIE_FIND_CB_END;
else if (!dwarf_diename(die_mem)) { /* Unnamed structure */
Dwarf_Die type_die, tmp_die;
if (die_get_type(die_mem, &type_die) &&
die_find_member(&type_die, name, &tmp_die))
return DIE_FIND_CB_END;
}
}
return DIE_FIND_CB_SIBLING;
}
/**
* die_find_member - Find a given name member in a data structure
* @st_die: a data structure type DIE
* @name: member name
* @die_mem: a buffer for result DIE
*
* Find a member DIE called @name in @st_die.
*/
Dwarf_Die *die_find_member(Dwarf_Die *st_die, const char *name,
Dwarf_Die *die_mem)
{
return die_find_child(st_die, __die_find_member_cb, (void *)name,
die_mem);
}
/**
* die_get_typename - Get the name of given variable DIE
* @vr_die: a variable DIE
* @buf: a strbuf for result type name
*
* Get the name of @vr_die and stores it to @buf. Return 0 if succeeded.
* and Return -ENOENT if failed to find type name.
* Note that the result will stores typedef name if possible, and stores
* "*(function_type)" if the type is a function pointer.
*/
int die_get_typename(Dwarf_Die *vr_die, struct strbuf *buf)
{
Dwarf_Die type;
int tag, ret;
const char *tmp = "";
if (__die_get_real_type(vr_die, &type) == NULL)
return -ENOENT;
tag = dwarf_tag(&type);
if (tag == DW_TAG_array_type || tag == DW_TAG_pointer_type)
tmp = "*";
else if (tag == DW_TAG_subroutine_type) {
/* Function pointer */
return strbuf_add(buf, "(function_type)", 15);
} else {
if (!dwarf_diename(&type))
return -ENOENT;
if (tag == DW_TAG_union_type)
tmp = "union ";
else if (tag == DW_TAG_structure_type)
tmp = "struct ";
else if (tag == DW_TAG_enumeration_type)
tmp = "enum ";
/* Write a base name */
return strbuf_addf(buf, "%s%s", tmp, dwarf_diename(&type));
}
ret = die_get_typename(&type, buf);
return ret ? ret : strbuf_addstr(buf, tmp);
}
/**
* die_get_varname - Get the name and type of given variable DIE
* @vr_die: a variable DIE
* @buf: a strbuf for type and variable name
*
* Get the name and type of @vr_die and stores it in @buf as "type\tname".
*/
int die_get_varname(Dwarf_Die *vr_die, struct strbuf *buf)
{
int ret;
ret = die_get_typename(vr_die, buf);
if (ret < 0) {
pr_debug("Failed to get type, make it unknown.\n");
ret = strbuf_add(buf, " (unknown_type)", 14);
}
return ret < 0 ? ret : strbuf_addf(buf, "\t%s", dwarf_diename(vr_die));
}
#ifdef HAVE_DWARF_GETLOCATIONS
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
/**
* die_get_var_innermost_scope - Get innermost scope range of given variable DIE
* @sp_die: a subprogram DIE
* @vr_die: a variable DIE
* @buf: a strbuf for variable byte offset range
*
* Get the innermost scope range of @vr_die and stores it in @buf as
* "@<function_name+[NN-NN,NN-NN]>".
*/
static int die_get_var_innermost_scope(Dwarf_Die *sp_die, Dwarf_Die *vr_die,
struct strbuf *buf)
{
Dwarf_Die *scopes;
int count;
size_t offset = 0;
Dwarf_Addr base;
Dwarf_Addr start, end;
Dwarf_Addr entry;
int ret;
bool first = true;
const char *name;
ret = dwarf_entrypc(sp_die, &entry);
if (ret)
return ret;
name = dwarf_diename(sp_die);
if (!name)
return -ENOENT;
count = dwarf_getscopes_die(vr_die, &scopes);
/* (*SCOPES)[1] is the DIE for the scope containing that scope */
if (count <= 1) {
ret = -EINVAL;
goto out;
}
while ((offset = dwarf_ranges(&scopes[1], offset, &base,
&start, &end)) > 0) {
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
start -= entry;
end -= entry;
if (first) {
ret = strbuf_addf(buf, "@<%s+[%" PRIu64 "-%" PRIu64,
name, start, end);
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
first = false;
} else {
ret = strbuf_addf(buf, ",%" PRIu64 "-%" PRIu64,
start, end);
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
}
if (ret < 0)
goto out;
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
}
if (!first)
ret = strbuf_add(buf, "]>", 2);
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
out:
free(scopes);
return ret;
}
/**
* die_get_var_range - Get byte offset range of given variable DIE
* @sp_die: a subprogram DIE
* @vr_die: a variable DIE
* @buf: a strbuf for type and variable name and byte offset range
*
* Get the byte offset range of @vr_die and stores it in @buf as
* "@<function_name+[NN-NN,NN-NN]>".
*/
int die_get_var_range(Dwarf_Die *sp_die, Dwarf_Die *vr_die, struct strbuf *buf)
{
int ret = 0;
Dwarf_Addr base;
Dwarf_Addr start, end;
Dwarf_Addr entry;
Dwarf_Op *op;
size_t nops;
size_t offset = 0;
Dwarf_Attribute attr;
bool first = true;
const char *name;
ret = dwarf_entrypc(sp_die, &entry);
if (ret)
return ret;
name = dwarf_diename(sp_die);
if (!name)
return -ENOENT;
if (dwarf_attr(vr_die, DW_AT_location, &attr) == NULL)
return -EINVAL;
while ((offset = dwarf_getlocations(&attr, offset, &base,
&start, &end, &op, &nops)) > 0) {
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
if (start == 0) {
/* Single Location Descriptions */
ret = die_get_var_innermost_scope(sp_die, vr_die, buf);
goto out;
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
}
/* Location Lists */
start -= entry;
end -= entry;
if (first) {
ret = strbuf_addf(buf, "@<%s+[%" PRIu64 "-%" PRIu64,
name, start, end);
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
first = false;
} else {
ret = strbuf_addf(buf, ",%" PRIu64 "-%" PRIu64,
start, end);
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
}
if (ret < 0)
goto out;
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
}
if (!first)
ret = strbuf_add(buf, "]>", 2);
out:
perf probe: Add --range option to show a variable's location range 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: He Kuang <hekuang@huawei.com> Acked-by: Masami 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.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-11 17:25:03 +08:00
return ret;
}
#else
int die_get_var_range(Dwarf_Die *sp_die __maybe_unused,
Dwarf_Die *vr_die __maybe_unused,
struct strbuf *buf __maybe_unused)
{
return -ENOTSUP;
}
#endif
/*
* die_has_loclist - Check if DW_AT_location of @vr_die is a location list
* @vr_die: a variable DIE
*/
static bool die_has_loclist(Dwarf_Die *vr_die)
{
Dwarf_Attribute loc;
int tag = dwarf_tag(vr_die);
if (tag != DW_TAG_formal_parameter &&
tag != DW_TAG_variable)
return false;
return (dwarf_attr_integrate(vr_die, DW_AT_location, &loc) &&
dwarf_whatform(&loc) == DW_FORM_sec_offset);
}
/*
* die_is_optimized_target - Check if target program is compiled with
* optimization
* @cu_die: a CU DIE
*
* For any object in given CU whose DW_AT_location is a location list,
* target program is compiled with optimization. This is applicable to
* clang as well.
*/
bool die_is_optimized_target(Dwarf_Die *cu_die)
{
Dwarf_Die tmp_die;
if (die_has_loclist(cu_die))
return true;
if (!dwarf_child(cu_die, &tmp_die) &&
die_is_optimized_target(&tmp_die))
return true;
if (!dwarf_siblingof(cu_die, &tmp_die) &&
die_is_optimized_target(&tmp_die))
return true;
return false;
}
/*
* die_search_idx - Search index of given line address
* @lines: Line records of single CU
* @nr_lines: Number of @lines
* @addr: address we are looking for
* @idx: index to be set by this function (return value)
*
* Search for @addr by looping over every lines of CU. If address
* matches, set index of that line in @idx. Note that single source
* line can have multiple line records. i.e. single source line can
* have multiple index.
*/
static bool die_search_idx(Dwarf_Lines *lines, unsigned long nr_lines,
Dwarf_Addr addr, unsigned long *idx)
{
unsigned long i;
Dwarf_Addr tmp;
for (i = 0; i < nr_lines; i++) {
if (dwarf_lineaddr(dwarf_onesrcline(lines, i), &tmp))
return false;
if (tmp == addr) {
*idx = i;
return true;
}
}
return false;
}
/*
* die_get_postprologue_addr - Search next address after function prologue
* @entrypc_idx: entrypc index
* @lines: Line records of single CU
* @nr_lines: Number of @lines
* @hignpc: high PC address of function
* @postprologue_addr: Next address after function prologue (return value)
*
* Look for prologue-end marker. If there is no explicit marker, return
* address of next line record or next source line.
*/
static bool die_get_postprologue_addr(unsigned long entrypc_idx,
Dwarf_Lines *lines,
unsigned long nr_lines,
Dwarf_Addr highpc,
Dwarf_Addr *postprologue_addr)
{
unsigned long i;
int entrypc_lno, lno;
Dwarf_Line *line;
Dwarf_Addr addr;
bool p_end;
/* entrypc_lno is actual source line number */
line = dwarf_onesrcline(lines, entrypc_idx);
if (dwarf_lineno(line, &entrypc_lno))
return false;
for (i = entrypc_idx; i < nr_lines; i++) {
line = dwarf_onesrcline(lines, i);
if (dwarf_lineaddr(line, &addr) ||
dwarf_lineno(line, &lno) ||
dwarf_lineprologueend(line, &p_end))
return false;
/* highpc is exclusive. [entrypc,highpc) */
if (addr >= highpc)
break;
/* clang supports prologue-end marker */
if (p_end)
break;
/* Actual next line in source */
if (lno != entrypc_lno)
break;
/*
* Single source line can have multiple line records.
* For Example,
* void foo() { printf("hello\n"); }
* contains two line records. One points to declaration and
* other points to printf() line. Variable 'lno' won't get
* incremented in this case but 'i' will.
*/
if (i != entrypc_idx)
break;
}
dwarf_lineaddr(line, postprologue_addr);
if (*postprologue_addr >= highpc)
dwarf_lineaddr(dwarf_onesrcline(lines, i - 1),
postprologue_addr);
return true;
}
/*
* die_skip_prologue - Use next address after prologue as probe location
* @sp_die: a subprogram DIE
* @cu_die: a CU DIE
* @entrypc: entrypc of the function
*
* Function prologue prepares stack and registers before executing function
* logic. When target program is compiled without optimization, function
* parameter information is only valid after prologue. When we probe entrypc
* of the function, and try to record function parameter, it contains
* garbage value.
*/
void die_skip_prologue(Dwarf_Die *sp_die, Dwarf_Die *cu_die,
Dwarf_Addr *entrypc)
{
size_t nr_lines = 0;
unsigned long entrypc_idx = 0;
Dwarf_Lines *lines = NULL;
Dwarf_Addr postprologue_addr;
Dwarf_Addr highpc;
if (dwarf_highpc(sp_die, &highpc))
return;
if (dwarf_getsrclines(cu_die, &lines, &nr_lines))
return;
if (!die_search_idx(lines, nr_lines, *entrypc, &entrypc_idx))
return;
if (!die_get_postprologue_addr(entrypc_idx, lines, nr_lines,
highpc, &postprologue_addr))
return;
*entrypc = postprologue_addr;
}