2009-08-12 11:07:25 +02:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2011-01-22 20:37:02 -02:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
|
2016-09-12 16:47:57 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2012-07-20 17:25:47 -06:00
|
|
|
|
2012-07-20 17:25:51 -06:00
|
|
|
|
2012-09-10 18:50:19 +02:00
|
|
|
|
2012-10-27 23:18:28 +02:00
|
|
|
|
2013-12-06 09:42:57 +02:00
|
|
|
|
2014-07-14 23:46:47 +02:00
|
|
|
|
2014-07-22 16:17:53 +03:00
|
|
|
|
2013-01-24 22:16:43 -03:00
|
|
|
|
2016-07-04 14:16:23 +02:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
2010-02-22 16:15:39 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-06 04:58:27 +00:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2016-09-12 16:47:57 -03:00
|
|
|
|
2016-09-06 04:58:27 +00:00
|
|
|
|
2015-11-26 03:42:32 -08:00
|
|
|
|
|
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
2011-08-24 15:18:34 +02:00
|
|
|
|
|
|
|
|
|
2012-11-07 16:27:11 +09:00
|
|
|
|
2014-08-19 22:31:14 -04:00
|
|
|
|
2011-08-24 15:18:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 11:48:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-27 16:29:16 -02:00
|
|
|
|
2009-10-30 16:28:23 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 16:14:36 +02:00
|
|
|
|
2015-06-02 11:53:26 -03:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
2009-10-30 16:28:23 -02:00
|
|
|
|
|
|
|
|
|
2014-07-22 16:17:53 +03:00
|
|
|
|
2013-08-21 12:10:25 +02:00
|
|
|
|
2014-05-19 15:13:49 -04:00
|
|
|
|
2014-07-22 16:18:00 +03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2009-10-30 16:28:23 -02:00
|
|
|
|
2014-05-20 11:48:50 +02:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2014-05-20 11:48:50 +02:00
|
|
|
|
2016-09-06 04:58:27 +00:00
|
|
|
|
2012-09-10 18:50:19 +02:00
|
|
|
|
2011-08-24 15:18:34 +02:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2013-08-21 12:10:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 15:13:49 -04:00
|
|
|
|
|
|
|
|
|
2013-08-21 12:10:25 +02:00
|
|
|
|
2014-01-16 10:49:31 +09:00
|
|
|
|
2010-03-25 19:58:57 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 11:48:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-10 18:50:19 +02:00
|
|
|
|
|
|
|
|
|
perf machine: Fix up vdso methods names
To make it consistent with the other dso lifetime routines.
For instance:
struct dso *vdso__new(struct machine *machine, const char *short_name,
const char *long_name)
Becomes:
struct dso *machine__addnew_vdso(struct machine *machine, const
char *short_name, const char *long_name)
Because:
1) There is no 'struct vdso' for us to have vdso__ prefixed routines.
2) Because it will not really just create a new instance of 'struct
dso', it'll call dso__new() but it will also insert it into the
DSO's list/rbtree, and we have a method name for that: 'addnew',
just like we have dsos__addnew().
3) So it is really a 'struct machine' operation, it is the first
argument, etc.
This way the place where this is used gets consistent:
if (vdso) {
pgoff = 0;
- dso = vdso__dso_findnew(machine, thread);
+ dso = machine__findnew_vdso(machine, thread);
} else
dso = machine__findnew_dso(machine, filename);
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/n/tip-r3w3tvh8exm9xfz3p4tz9qbz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-29 11:54:08 -03:00
|
|
|
|
2012-09-10 18:50:19 +02:00
|
|
|
|
2015-05-29 11:31:12 -03:00
|
|
|
|
2012-09-10 18:50:19 +02:00
|
|
|
|
2009-10-30 16:28:23 -02:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-10-30 16:28:23 -02:00
|
|
|
|
2011-08-24 15:18:34 +02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2011-08-24 15:18:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-16 10:49:31 +09:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2010-02-03 16:52:02 -02:00
|
|
|
|
2015-06-02 11:53:26 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-06 13:41:20 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-23 11:06:16 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-30 11:54:04 -03:00
|
|
|
|
2015-07-23 11:06:16 -03:00
|
|
|
|
|
|
|
|
|
2015-06-02 11:53:26 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
2015-05-25 15:30:09 -03:00
|
|
|
|
2015-06-02 11:53:26 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
|
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-24 13:01:52 -02:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-24 13:01:52 -02:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-11-20 20:51:27 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-30 16:28:25 -02:00
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-12-15 10:32:33 -05:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-12-15 10:32:33 -05:00
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2016-05-11 22:51:59 +09:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
|
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-30 12:07:11 +02:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-18 18:44:45 -06:00
|
|
|
|
|
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-06 13:41:21 +09:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-28 17:35:37 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2009-10-28 21:51:21 -02:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2009-10-28 21:51:21 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-10-28 21:51:21 -02:00
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
|
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
perf symbols: Allow lookups by symbol name too
Configurable via symbol_conf.sort_by_name, so that the cost of an
extra rb_node on all 'struct symbol' instances is not paid by tools
that only want to decode addresses.
How to use it:
symbol_conf.sort_by_name = true;
symbol_init(&symbol_conf);
struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
if (map == NULL) {
pr_err("couldn't find map!\n");
kernel_maps__fprintf(stdout);
} else {
struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
if (sym == NULL)
pr_err("couldn't find symbol %s!\n", sym_filter);
else
pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
}
Looking over the vmlinux/kallsyms is common enough that I'll add a
variable to the upcoming struct perf_session to avoid the need to
use map_groups__find_by_name to get the main vmlinux/kallsyms map.
The above example looks on the 'variable' symtab, but it is just
like that for the functions one.
Also the sort operation is done when we first use
map__find_symbol_by_name, in a lazy way.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-11 18:50:22 -02:00
|
|
|
|
|
|
|
|
|
2015-08-18 15:19:50 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2015-08-18 15:19:50 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
2011-01-22 20:37:02 -02:00
|
|
|
|
2013-01-24 21:59:59 -03:00
|
|
|
|
2009-08-12 11:07:25 +02:00
|
|
|
|
perf annotate: Fix it for non-prelinked *.so
The problem was we were incorrectly calculating objdump
addresses for sym->start and sym->end, look:
For simple ET_DYN type DSO (*.so) with one function, objdump -dS
output is something like this:
000004ac <my_strlen>:
int my_strlen(const char *s)
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 10 sub $0x10,%esp
{
i.e. we have relative-to-dso-mapping IPs (=RIP) there.
For ET_EXEC type and probably for prelinked libs as well (sorry
can't test - I don't use prelink) objdump outputs absolute IPs,
e.g.
08048604 <zz_strlen>:
extern "C"
int zz_strlen(const char *s)
8048604: 55 push %ebp
8048605: 89 e5 mov %esp,%ebp
8048607: 83 ec 10 sub $0x10,%esp
{
So, if sym->start is always relative to dso mapping(*), we'll
have to unmap it for ET_EXEC like cases, and leave as is for
ET_DYN cases.
(*) and it is - we've explicitely made it relative. Look for
adjust_symbols handling in dso__load_sym()
Previously we were always unmapping sym->start and for ET_DYN
dsos resulting addresses were wrong, and so objdump output was
empty.
The end result was that perf annotate output for symbols from
non-prelinked *.so had always 0.00% percents only, which is
wrong.
To fix it, let's introduce a helper for converting rip to
objdump address, and also let's document what map_ip() and
unmap_ip() do -- I had to study sources for several hours to
understand it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1265223128-11786-8-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-03 16:52:07 -02:00
|
|
|
|
2012-01-30 13:42:57 +09:00
|
|
|
|
|
|
|
|
|
2012-08-27 15:38:26 +08:00
|
|
|
|
2012-01-30 13:42:57 +09:00
|
|
|
|
2012-01-30 13:43:20 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-27 15:38:26 +08:00
|
|
|
|
2012-01-30 13:42:57 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-06 09:42:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-12 18:05:27 -08:00
|
|
|
|
2013-12-06 09:42:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-14 13:43:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
perf annotate: Fix it for non-prelinked *.so
The problem was we were incorrectly calculating objdump
addresses for sym->start and sym->end, look:
For simple ET_DYN type DSO (*.so) with one function, objdump -dS
output is something like this:
000004ac <my_strlen>:
int my_strlen(const char *s)
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 10 sub $0x10,%esp
{
i.e. we have relative-to-dso-mapping IPs (=RIP) there.
For ET_EXEC type and probably for prelinked libs as well (sorry
can't test - I don't use prelink) objdump outputs absolute IPs,
e.g.
08048604 <zz_strlen>:
extern "C"
int zz_strlen(const char *s)
8048604: 55 push %ebp
8048605: 89 e5 mov %esp,%ebp
8048607: 83 ec 10 sub $0x10,%esp
{
So, if sym->start is always relative to dso mapping(*), we'll
have to unmap it for ET_EXEC like cases, and leave as is for
ET_DYN cases.
(*) and it is - we've explicitely made it relative. Look for
adjust_symbols handling in dso__load_sym()
Previously we were always unmapping sym->start and for ET_DYN
dsos resulting addresses were wrong, and so objdump output was
empty.
The end result was that perf annotate output for symbols from
non-prelinked *.so had always 0.00% percents only, which is
wrong.
To fix it, let's introduce a helper for converting rip to
objdump address, and also let's document what map_ip() and
unmap_ip() do -- I had to study sources for several hours to
understand it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1265223128-11786-8-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-03 16:52:07 -02:00
|
|
|
|
2013-08-07 14:38:50 +03:00
|
|
|
|
|
|
|
|
|
2013-10-14 13:43:44 +03:00
|
|
|
|
|
|
|
|
|
perf annotate: Fix it for non-prelinked *.so
The problem was we were incorrectly calculating objdump
addresses for sym->start and sym->end, look:
For simple ET_DYN type DSO (*.so) with one function, objdump -dS
output is something like this:
000004ac <my_strlen>:
int my_strlen(const char *s)
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 10 sub $0x10,%esp
{
i.e. we have relative-to-dso-mapping IPs (=RIP) there.
For ET_EXEC type and probably for prelinked libs as well (sorry
can't test - I don't use prelink) objdump outputs absolute IPs,
e.g.
08048604 <zz_strlen>:
extern "C"
int zz_strlen(const char *s)
8048604: 55 push %ebp
8048605: 89 e5 mov %esp,%ebp
8048607: 83 ec 10 sub $0x10,%esp
{
So, if sym->start is always relative to dso mapping(*), we'll
have to unmap it for ET_EXEC like cases, and leave as is for
ET_DYN cases.
(*) and it is - we've explicitely made it relative. Look for
adjust_symbols handling in dso__load_sym()
Previously we were always unmapping sym->start and for ET_DYN
dsos resulting addresses were wrong, and so objdump output was
empty.
The end result was that perf annotate output for symbols from
non-prelinked *.so had always 0.00% percents only, which is
wrong.
To fix it, let's introduce a helper for converting rip to
objdump address, and also let's document what map_ip() and
unmap_ip() do -- I had to study sources for several hours to
understand it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1265223128-11786-8-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-03 16:52:07 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 14:38:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-07 10:24:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 16:14:36 +02:00
|
|
|
|
perf annotate: Fix it for non-prelinked *.so
The problem was we were incorrectly calculating objdump
addresses for sym->start and sym->end, look:
For simple ET_DYN type DSO (*.so) with one function, objdump -dS
output is something like this:
000004ac <my_strlen>:
int my_strlen(const char *s)
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 10 sub $0x10,%esp
{
i.e. we have relative-to-dso-mapping IPs (=RIP) there.
For ET_EXEC type and probably for prelinked libs as well (sorry
can't test - I don't use prelink) objdump outputs absolute IPs,
e.g.
08048604 <zz_strlen>:
extern "C"
int zz_strlen(const char *s)
8048604: 55 push %ebp
8048605: 89 e5 mov %esp,%ebp
8048607: 83 ec 10 sub $0x10,%esp
{
So, if sym->start is always relative to dso mapping(*), we'll
have to unmap it for ET_EXEC like cases, and leave as is for
ET_DYN cases.
(*) and it is - we've explicitely made it relative. Look for
adjust_symbols handling in dso__load_sym()
Previously we were always unmapping sym->start and for ET_DYN
dsos resulting addresses were wrong, and so objdump output was
empty.
The end result was that perf annotate output for symbols from
non-prelinked *.so had always 0.00% percents only, which is
wrong.
To fix it, let's introduce a helper for converting rip to
objdump address, and also let's document what map_ip() and
unmap_ip() do -- I had to study sources for several hours to
understand it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1265223128-11786-8-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-03 16:52:07 -02:00
|
|
|
|
perf top: Fix annotate for userspace
First, for programs and prelinked libraries, annotate code was
fooled by objdump output IPs (src->eip in the code) being
wrongly converted to absolute IPs. In such case there were no
conversion needed, but in
src->eip = strtoull(src->line, NULL, 16);
src->eip = map->unmap_ip(map, src->eip); // = eip + map->start - map->pgoff
we were reading absolute address from objdump (e.g. 8048604) and
then almost doubling it, because eip & map->start are
approximately close for small programs.
Needless to say, that later, in record_precise_ip() there was no
matching with real runtime IPs.
And second, like with `perf annotate` the problem with
non-prelinked *.so was that we were doing rip -> objdump address
conversion wrong.
Also, because unlike `perf annotate`, `perf top` code does
annotation based on absolute IPs for performance reasons(*), new
helper for mapping objdump addresse to IP is introduced.
(*) we get samples info in absolute IPs, and since we do lots of
hit-testing on absolute IPs at runtime in record_precise_ip(), it's
better to convert objdump addresses to IPs once and do no conversion
at runtime.
I also had to fix how objdump output is parsed (with hardcoded
8/16 characters format, which was inappropriate for ET_DYN dsos
with small addresses like '4ac')
Also note, that not all objdump output lines has associtated
IPs, e.g. look at source lines here:
000004ac <my_strlen>:
extern "C"
int my_strlen(const char *s)
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 10 sub $0x10,%esp
{
int len = 0;
4b2: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp)
4b9: eb 08 jmp 4c3 <my_strlen+0x17>
while (*s) {
++len;
4bb: 83 45 fc 01 addl $0x1,-0x4(%ebp)
++s;
4bf: 83 45 08 01 addl $0x1,0x8(%ebp)
So we mark them with eip=0, and ignore such lines in annotate
lookup code.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
[ Note: one hunk of this patch was applied by Mike in 57d8188 ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1265550376-12665-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-07 11:46:15 -02:00
|
|
|
|
2013-10-14 13:43:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-07 10:24:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 16:14:36 +02:00
|
|
|
|
2013-10-14 13:43:44 +03:00
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
2014-10-21 17:29:02 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2014-10-21 17:29:02 -03:00
|
|
|
|
2015-05-15 15:20:44 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-07-30 18:28:42 -03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
2010-07-30 18:28:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-25 15:30:09 -03:00
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
2010-07-30 18:28:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
2011-08-23 14:31:30 -03:00
|
|
|
|
2010-07-30 18:28:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
|
|
|
|
|
2010-07-30 18:28:42 -03:00
|
|
|
|
|
|
|
|
|
2014-07-16 11:07:13 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-21 17:29:02 -03:00
|
|
|
|
2014-03-21 17:57:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-21 17:29:02 -03:00
|
|
|
|
2014-03-21 17:57:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-25 15:26:44 -03:00
|
|
|
|
|
|
|
|
|
2015-05-15 15:20:44 -03:00
|
|
|
|
2014-03-25 15:26:44 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-23 14:31:30 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2011-08-23 14:31:30 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2014-01-23 02:29:50 +00:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-29 17:34:46 -03:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:30:40 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
2015-09-29 17:34:46 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2015-09-29 17:34:46 -03:00
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2015-09-29 17:34:46 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2013-10-14 13:43:38 +03:00
|
|
|
|
2014-10-06 10:35:32 +02:00
|
|
|
|
2013-10-14 13:43:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-01 19:25:52 -03:00
|
|
|
|
2013-10-14 13:43:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-15 23:29:51 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-14 23:46:47 +02:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
perf tools: Insert split maps correctly into origin group
When new maps are cloned out of split map they are added into origin
map's group, but their groups pointer is not updated.
This could lead to a segfault, because map->groups is expected to be
always set as reported by Markus:
__map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
238 return __machine__kernel_map(map->groups->machine, map->type) =
(gdb) bt
#0 __map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
#1 0x00000000004393e4 in symbol_filter (map=map@entry=0x1abb7a0, sym=sym@entry
#2 0x00000000004fcd4d in dso__load_sym (dso=dso@entry=0x166dae0, map=map@entry
#3 0x00000000004a64e0 in dso__load (dso=0x166dae0, map=map@entry=0x1abb7a0, fi
#4 0x00000000004b941f in map__load (filter=0x4393c0 <symbol_filter>, map=<opti
#5 map__find_symbol (map=0x1abb7a0, addr=40188, filter=0x4393c0 <symbol_filter
...
Adding __map_groups__insert function to add map into groups together
with map->groups pointer update. It takes no lock as opposed to existing
map_groups__insert, as maps__fixup_overlappings(), where it is being
called, already has the necessary lock held.
Using __map_groups__insert to add new maps after map split.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20151104140811.GA32664@krava.brq.redhat.com
Fixes: cfc5acd4c80b ("perf top: Filter symbols based on __map__is_kernel(map)")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-11-04 15:08:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-25 15:30:09 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
|
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2014-10-06 10:35:32 +02:00
|
|
|
|
perf tools: Insert split maps correctly into origin group
When new maps are cloned out of split map they are added into origin
map's group, but their groups pointer is not updated.
This could lead to a segfault, because map->groups is expected to be
always set as reported by Markus:
__map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
238 return __machine__kernel_map(map->groups->machine, map->type) =
(gdb) bt
#0 __map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
#1 0x00000000004393e4 in symbol_filter (map=map@entry=0x1abb7a0, sym=sym@entry
#2 0x00000000004fcd4d in dso__load_sym (dso=dso@entry=0x166dae0, map=map@entry
#3 0x00000000004a64e0 in dso__load (dso=0x166dae0, map=map@entry=0x1abb7a0, fi
#4 0x00000000004b941f in map__load (filter=0x4393c0 <symbol_filter>, map=<opti
#5 map__find_symbol (map=0x1abb7a0, addr=40188, filter=0x4393c0 <symbol_filter
...
Adding __map_groups__insert function to add map into groups together
with map->groups pointer update. It takes no lock as opposed to existing
map_groups__insert, as maps__fixup_overlappings(), where it is being
called, already has the necessary lock held.
Using __map_groups__insert to add new maps after map split.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20151104140811.GA32664@krava.brq.redhat.com
Fixes: cfc5acd4c80b ("perf top: Filter symbols based on __map__is_kernel(map)")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-11-04 15:08:11 +01:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-12-09 11:11:31 +09:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
|
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2014-10-06 10:35:32 +02:00
|
|
|
|
perf tools: Insert split maps correctly into origin group
When new maps are cloned out of split map they are added into origin
map's group, but their groups pointer is not updated.
This could lead to a segfault, because map->groups is expected to be
always set as reported by Markus:
__map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
238 return __machine__kernel_map(map->groups->machine, map->type) =
(gdb) bt
#0 __map__is_kernel (map=map@entry=0x1abb7a0) at util/map.c:238
#1 0x00000000004393e4 in symbol_filter (map=map@entry=0x1abb7a0, sym=sym@entry
#2 0x00000000004fcd4d in dso__load_sym (dso=dso@entry=0x166dae0, map=map@entry
#3 0x00000000004a64e0 in dso__load (dso=0x166dae0, map=map@entry=0x1abb7a0, fi
#4 0x00000000004b941f in map__load (filter=0x4393c0 <symbol_filter>, map=<opti
#5 map__find_symbol (map=0x1abb7a0, addr=40188, filter=0x4393c0 <symbol_filter
...
Adding __map_groups__insert function to add map into groups together
with map->groups pointer update. It takes no lock as opposed to existing
map_groups__insert, as maps__fixup_overlappings(), where it is being
called, already has the necessary lock held.
Using __map_groups__insert to add new maps after map split.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20151104140811.GA32664@krava.brq.redhat.com
Fixes: cfc5acd4c80b ("perf top: Filter symbols based on __map__is_kernel(map)")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-11-04 15:08:11 +01:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-12-09 11:11:31 +09:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
2015-06-15 23:29:51 -03:00
|
|
|
|
perf tools: Don't keep unreferenced maps when unmaps are detected
For a file with:
[root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
TOTAL events: 36933
MMAP events: 9056
LOST events: 0
COMM events: 1702
EXIT events: 1887
THROTTLE events: 8
UNTHROTTLE events: 8
FORK events: 1894
READ events: 0
SAMPLE events: 22378
ATTR events: 0
EVENT_TYPE events: 0
TRACING_DATA events: 0
BUILD_ID events: 0
[root@emilia linux-2.6-tip]#
Testing with valgrind and making perf_session__delete() a nop, so that
we can notice how many maps were actually deleted due to not having any
samples on it:
==== HEAP SUMMARY:
Before:
==10339== in use at exit: 8,909,997 bytes in 68,690 blocks
==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
After:
==10506== in use at exit: 8,902,605 bytes in 68,606 blocks
==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
not much, but in some other long running workload this may save more
bytes.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 19:45:23 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-04 14:16:23 +02:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2016-07-04 14:16:23 +02:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2015-05-22 11:52:22 -03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2015-05-22 11:52:22 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 11:52:22 -03:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2016-07-04 14:16:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-23 14:31:30 -03:00
|
|
|
|
2015-12-09 11:11:20 +09:00
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-26 12:11:06 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
perf session: Free the ref_reloc_sym memory at the right place
Which is at perf_session__destroy_kernel_maps, counterpart to the
perf_session__create_kernel_maps where the kmap structure is located, just
after the vmlinux_maps.
Make it also check if the kernel maps were actually created, which may not
be the case if, for instance, perf_session__new can't complete due to
permission problems in, for instance, a 'perf report' case, when a
segfault will take place, that is how this was noticed.
The problem was introduced in d65a458, thus post .35.
This also adds code to release guest machines as them are also created
in perf_session__create_kernel_maps, so should be deleted on this newly
introduced counterpart, perf_session__destroy_kernel_maps.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 18:18:28 -03:00
|
|
|
|
2015-05-25 15:30:09 -03:00
|
|
|
|
2015-05-25 16:59:56 -03:00
|
|
|
|
perf session: Free the ref_reloc_sym memory at the right place
Which is at perf_session__destroy_kernel_maps, counterpart to the
perf_session__create_kernel_maps where the kmap structure is located, just
after the vmlinux_maps.
Make it also check if the kernel maps were actually created, which may not
be the case if, for instance, perf_session__new can't complete due to
permission problems in, for instance, a 'perf report' case, when a
segfault will take place, that is how this was noticed.
The problem was introduced in d65a458, thus post .35.
This also adds code to release guest machines as them are also created
in perf_session__create_kernel_maps, so should be deleted on this newly
introduced counterpart, perf_session__destroy_kernel_maps.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 18:18:28 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-14 16:05:38 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
|
|
|
|
|
2015-05-22 13:45:24 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-25 19:58:58 -03:00
|
|
|
|
2013-08-07 14:38:51 +03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2013-08-07 14:38:51 +03:00
|
|
|
|
2015-05-22 12:58:53 -03:00
|
|
|
|
2013-08-07 14:38:51 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-21 17:48:33 -03:00
|
|
|
|
2013-08-07 14:38:51 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-07 08:22:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
