2009-10-27 04:23:18 +07:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include "event.h"
|
|
|
|
#include "debug.h"
|
2009-12-16 05:04:41 +07:00
|
|
|
#include "sort.h"
|
2009-10-27 04:23:18 +07:00
|
|
|
#include "string.h"
|
2009-12-16 05:04:41 +07:00
|
|
|
#include "strlist.h"
|
2009-11-28 01:29:22 +07:00
|
|
|
#include "thread.h"
|
2011-02-11 20:45:54 +07:00
|
|
|
#include "thread_map.h"
|
2009-10-27 04:23:18 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
static const char *perf_event__names[] = {
|
2011-05-23 18:06:27 +07:00
|
|
|
[0] = "TOTAL",
|
|
|
|
[PERF_RECORD_MMAP] = "MMAP",
|
|
|
|
[PERF_RECORD_LOST] = "LOST",
|
|
|
|
[PERF_RECORD_COMM] = "COMM",
|
|
|
|
[PERF_RECORD_EXIT] = "EXIT",
|
|
|
|
[PERF_RECORD_THROTTLE] = "THROTTLE",
|
|
|
|
[PERF_RECORD_UNTHROTTLE] = "UNTHROTTLE",
|
|
|
|
[PERF_RECORD_FORK] = "FORK",
|
|
|
|
[PERF_RECORD_READ] = "READ",
|
|
|
|
[PERF_RECORD_SAMPLE] = "SAMPLE",
|
|
|
|
[PERF_RECORD_HEADER_ATTR] = "ATTR",
|
|
|
|
[PERF_RECORD_HEADER_EVENT_TYPE] = "EVENT_TYPE",
|
|
|
|
[PERF_RECORD_HEADER_TRACING_DATA] = "TRACING_DATA",
|
|
|
|
[PERF_RECORD_HEADER_BUILD_ID] = "BUILD_ID",
|
|
|
|
[PERF_RECORD_FINISHED_ROUND] = "FINISHED_ROUND",
|
2010-05-14 20:36:42 +07:00
|
|
|
};
|
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
const char *perf_event__name(unsigned int id)
|
2010-12-07 19:48:42 +07:00
|
|
|
{
|
2011-01-29 23:01:45 +07:00
|
|
|
if (id >= ARRAY_SIZE(perf_event__names))
|
2010-12-07 19:48:42 +07:00
|
|
|
return "INVALID";
|
2011-01-29 23:01:45 +07:00
|
|
|
if (!perf_event__names[id])
|
2010-12-07 19:48:42 +07:00
|
|
|
return "UNKNOWN";
|
2011-01-29 23:01:45 +07:00
|
|
|
return perf_event__names[id];
|
2010-12-07 19:48:42 +07:00
|
|
|
}
|
|
|
|
|
2011-01-29 22:02:00 +07:00
|
|
|
static struct perf_sample synth_sample = {
|
perf session: Parse sample earlier
At perf_session__process_event, so that we reduce the number of lines in eache
tool sample processing routine that now receives a sample_data pointer already
parsed.
This will also be useful in the next patch, where we'll allow sample the
identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
timestamp) just after before every event.
Also validate callchains in perf_session__process_event, i.e. as early as
possible, and keep a counter of the number of events discarded due to invalid
callchains, warning the user about it if it happens.
There is an assumption that was kept that all events have the same sample_type,
that will be dealt with in the future, when this preexisting limitation will be
removed.
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-12-02 23:10:21 +07:00
|
|
|
.pid = -1,
|
|
|
|
.tid = -1,
|
|
|
|
.time = -1,
|
|
|
|
.stream_id = -1,
|
|
|
|
.cpu = -1,
|
|
|
|
.period = 1,
|
|
|
|
};
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event, pid_t pid,
|
2011-01-29 23:01:45 +07:00
|
|
|
int full, perf_event__handler_t process,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-10-27 04:23:18 +07:00
|
|
|
{
|
|
|
|
char filename[PATH_MAX];
|
|
|
|
char bf[BUFSIZ];
|
|
|
|
FILE *fp;
|
|
|
|
size_t size = 0;
|
|
|
|
DIR *tasks;
|
|
|
|
struct dirent dirent, *next;
|
|
|
|
pid_t tgid = 0;
|
|
|
|
|
|
|
|
snprintf(filename, sizeof(filename), "/proc/%d/status", pid);
|
|
|
|
|
|
|
|
fp = fopen(filename, "r");
|
|
|
|
if (fp == NULL) {
|
|
|
|
out_race:
|
|
|
|
/*
|
|
|
|
* We raced with a task exiting - just return:
|
|
|
|
*/
|
|
|
|
pr_debug("couldn't open %s\n", filename);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
memset(&event->comm, 0, sizeof(event->comm));
|
|
|
|
|
|
|
|
while (!event->comm.comm[0] || !event->comm.pid) {
|
|
|
|
if (fgets(bf, sizeof(bf), fp) == NULL) {
|
|
|
|
pr_warning("couldn't get COMM and pgid, malformed %s\n", filename);
|
|
|
|
goto out;
|
|
|
|
}
|
2009-10-27 04:23:18 +07:00
|
|
|
|
|
|
|
if (memcmp(bf, "Name:", 5) == 0) {
|
|
|
|
char *name = bf + 5;
|
|
|
|
while (*name && isspace(*name))
|
|
|
|
++name;
|
|
|
|
size = strlen(name) - 1;
|
2010-12-02 19:25:28 +07:00
|
|
|
memcpy(event->comm.comm, name, size++);
|
2009-10-27 04:23:18 +07:00
|
|
|
} else if (memcmp(bf, "Tgid:", 5) == 0) {
|
|
|
|
char *tgids = bf + 5;
|
|
|
|
while (*tgids && isspace(*tgids))
|
|
|
|
++tgids;
|
2010-12-02 19:25:28 +07:00
|
|
|
tgid = event->comm.pid = atoi(tgids);
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
event->comm.header.type = PERF_RECORD_COMM;
|
2009-10-27 04:23:18 +07:00
|
|
|
size = ALIGN(size, sizeof(u64));
|
2011-11-28 16:56:39 +07:00
|
|
|
memset(event->comm.comm + size, 0, machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
event->comm.header.size = (sizeof(event->comm) -
|
|
|
|
(sizeof(event->comm.comm) - size) +
|
2011-11-28 16:56:39 +07:00
|
|
|
machine->id_hdr_size);
|
2009-10-27 04:23:18 +07:00
|
|
|
if (!full) {
|
2010-12-02 19:25:28 +07:00
|
|
|
event->comm.tid = pid;
|
2009-10-27 04:23:18 +07:00
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
process(tool, event, &synth_sample, machine);
|
2010-12-02 19:25:28 +07:00
|
|
|
goto out;
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
snprintf(filename, sizeof(filename), "/proc/%d/task", pid);
|
|
|
|
|
|
|
|
tasks = opendir(filename);
|
|
|
|
if (tasks == NULL)
|
|
|
|
goto out_race;
|
|
|
|
|
|
|
|
while (!readdir_r(tasks, &dirent, &next) && next) {
|
|
|
|
char *end;
|
|
|
|
pid = strtol(dirent.d_name, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
continue;
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
event->comm.tid = pid;
|
2009-10-27 04:23:18 +07:00
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
process(tool, event, &synth_sample, machine);
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
closedir(tasks);
|
|
|
|
out:
|
2009-10-27 04:23:18 +07:00
|
|
|
fclose(fp);
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
return tgid;
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
static int perf_event__synthesize_mmap_events(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-01-29 23:01:45 +07:00
|
|
|
pid_t pid, pid_t tgid,
|
|
|
|
perf_event__handler_t process,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-10-27 04:23:18 +07:00
|
|
|
{
|
|
|
|
char filename[PATH_MAX];
|
|
|
|
FILE *fp;
|
|
|
|
|
|
|
|
snprintf(filename, sizeof(filename), "/proc/%d/maps", pid);
|
|
|
|
|
|
|
|
fp = fopen(filename, "r");
|
|
|
|
if (fp == NULL) {
|
|
|
|
/*
|
|
|
|
* We raced with a task exiting - just return:
|
|
|
|
*/
|
|
|
|
pr_debug("couldn't open %s\n", filename);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
event->header.type = PERF_RECORD_MMAP;
|
|
|
|
/*
|
|
|
|
* Just like the kernel, see __perf_event_mmap in kernel/perf_event.c
|
|
|
|
*/
|
|
|
|
event->header.misc = PERF_RECORD_MISC_USER;
|
|
|
|
|
2009-10-27 04:23:18 +07:00
|
|
|
while (1) {
|
|
|
|
char bf[BUFSIZ], *pbf = bf;
|
|
|
|
int n;
|
|
|
|
size_t size;
|
|
|
|
if (fgets(bf, sizeof(bf), fp) == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* 00400000-0040c000 r-xp 00000000 fd:01 41038 /bin/cat */
|
2010-12-02 19:25:28 +07:00
|
|
|
n = hex2u64(pbf, &event->mmap.start);
|
2009-10-27 04:23:18 +07:00
|
|
|
if (n < 0)
|
|
|
|
continue;
|
|
|
|
pbf += n + 1;
|
2010-12-02 19:25:28 +07:00
|
|
|
n = hex2u64(pbf, &event->mmap.len);
|
2009-10-27 04:23:18 +07:00
|
|
|
if (n < 0)
|
|
|
|
continue;
|
|
|
|
pbf += n + 3;
|
|
|
|
if (*pbf == 'x') { /* vm_exec */
|
2011-08-30 06:15:06 +07:00
|
|
|
char anonstr[] = "//anon\n";
|
2009-10-27 04:23:18 +07:00
|
|
|
char *execname = strchr(bf, '/');
|
|
|
|
|
|
|
|
/* Catch VDSO */
|
|
|
|
if (execname == NULL)
|
|
|
|
execname = strstr(bf, "[vdso]");
|
|
|
|
|
2011-08-30 06:15:06 +07:00
|
|
|
/* Catch anonymous mmaps */
|
|
|
|
if ((execname == NULL) && !strstr(bf, "["))
|
|
|
|
execname = anonstr;
|
|
|
|
|
2009-10-27 04:23:18 +07:00
|
|
|
if (execname == NULL)
|
|
|
|
continue;
|
|
|
|
|
2010-04-03 18:53:31 +07:00
|
|
|
pbf += 3;
|
2010-12-02 19:25:28 +07:00
|
|
|
n = hex2u64(pbf, &event->mmap.pgoff);
|
2010-04-03 18:53:31 +07:00
|
|
|
|
2009-10-27 04:23:18 +07:00
|
|
|
size = strlen(execname);
|
|
|
|
execname[size - 1] = '\0'; /* Remove \n */
|
2010-12-02 19:25:28 +07:00
|
|
|
memcpy(event->mmap.filename, execname, size);
|
2009-10-27 04:23:18 +07:00
|
|
|
size = ALIGN(size, sizeof(u64));
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.len -= event->mmap.start;
|
|
|
|
event->mmap.header.size = (sizeof(event->mmap) -
|
|
|
|
(sizeof(event->mmap.filename) - size));
|
2011-11-28 16:56:39 +07:00
|
|
|
memset(event->mmap.filename + size, 0, machine->id_hdr_size);
|
|
|
|
event->mmap.header.size += machine->id_hdr_size;
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.pid = tgid;
|
|
|
|
event->mmap.tid = pid;
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
process(tool, event, &synth_sample, machine);
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fclose(fp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__synthesize_modules(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
perf_event__handler_t process,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct machine *machine)
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
{
|
|
|
|
struct rb_node *nd;
|
2010-04-28 07:17:50 +07:00
|
|
|
struct map_groups *kmaps = &machine->kmaps;
|
2011-01-29 23:01:45 +07:00
|
|
|
union perf_event *event = zalloc((sizeof(event->mmap) +
|
2011-11-28 16:56:39 +07:00
|
|
|
machine->id_hdr_size));
|
2010-12-02 19:25:28 +07:00
|
|
|
if (event == NULL) {
|
|
|
|
pr_debug("Not enough memory synthesizing mmap event "
|
|
|
|
"for kernel modules\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
event->header.type = PERF_RECORD_MMAP;
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
|
2010-04-19 12:32:50 +07:00
|
|
|
/*
|
|
|
|
* kernel uses 0 for user space maps, see kernel/perf_event.c
|
|
|
|
* __perf_event_mmap
|
|
|
|
*/
|
2010-04-28 07:17:50 +07:00
|
|
|
if (machine__is_host(machine))
|
2010-12-02 19:25:28 +07:00
|
|
|
event->header.misc = PERF_RECORD_MISC_KERNEL;
|
2010-04-19 12:32:50 +07:00
|
|
|
else
|
2010-12-02 19:25:28 +07:00
|
|
|
event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
|
2010-04-19 12:32:50 +07:00
|
|
|
|
|
|
|
for (nd = rb_first(&kmaps->maps[MAP__FUNCTION]);
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
nd; nd = rb_next(nd)) {
|
|
|
|
size_t size;
|
|
|
|
struct map *pos = rb_entry(nd, struct map, rb_node);
|
|
|
|
|
|
|
|
if (pos->dso->kernel)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
size = ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.header.type = PERF_RECORD_MMAP;
|
|
|
|
event->mmap.header.size = (sizeof(event->mmap) -
|
|
|
|
(sizeof(event->mmap.filename) - size));
|
2011-11-28 16:56:39 +07:00
|
|
|
memset(event->mmap.filename + size, 0, machine->id_hdr_size);
|
|
|
|
event->mmap.header.size += machine->id_hdr_size;
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.start = pos->start;
|
|
|
|
event->mmap.len = pos->end - pos->start;
|
|
|
|
event->mmap.pid = machine->pid;
|
|
|
|
|
|
|
|
memcpy(event->mmap.filename, pos->dso->long_name,
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
pos->dso->long_name_len + 1);
|
2011-11-28 17:30:20 +07:00
|
|
|
process(tool, event, &synth_sample, machine);
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
}
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
free(event);
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
static int __event__synthesize_thread(union perf_event *comm_event,
|
|
|
|
union perf_event *mmap_event,
|
|
|
|
pid_t pid, perf_event__handler_t process,
|
2011-11-28 17:30:20 +07:00
|
|
|
struct perf_tool *tool,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-10-27 04:23:18 +07:00
|
|
|
{
|
2011-11-28 17:30:20 +07:00
|
|
|
pid_t tgid = perf_event__synthesize_comm(tool, comm_event, pid, 1,
|
2011-11-28 16:56:39 +07:00
|
|
|
process, machine);
|
2009-10-27 04:23:18 +07:00
|
|
|
if (tgid == -1)
|
|
|
|
return -1;
|
2011-11-28 17:30:20 +07:00
|
|
|
return perf_event__synthesize_mmap_events(tool, mmap_event, pid, tgid,
|
2011-11-28 16:56:39 +07:00
|
|
|
process, machine);
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__synthesize_thread_map(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
struct thread_map *threads,
|
2011-02-11 20:45:54 +07:00
|
|
|
perf_event__handler_t process,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2010-12-02 19:25:28 +07:00
|
|
|
{
|
2011-01-29 23:01:45 +07:00
|
|
|
union perf_event *comm_event, *mmap_event;
|
2011-02-10 21:52:47 +07:00
|
|
|
int err = -1, thread;
|
2010-12-02 19:25:28 +07:00
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
comm_event = malloc(sizeof(comm_event->comm) + machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
if (comm_event == NULL)
|
|
|
|
goto out;
|
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
mmap_event = malloc(sizeof(mmap_event->mmap) + machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
if (mmap_event == NULL)
|
|
|
|
goto out_free_comm;
|
|
|
|
|
2011-02-10 21:52:47 +07:00
|
|
|
err = 0;
|
|
|
|
for (thread = 0; thread < threads->nr; ++thread) {
|
|
|
|
if (__event__synthesize_thread(comm_event, mmap_event,
|
|
|
|
threads->map[thread],
|
2011-11-28 17:30:20 +07:00
|
|
|
process, tool, machine)) {
|
2011-02-10 21:52:47 +07:00
|
|
|
err = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2010-12-02 19:25:28 +07:00
|
|
|
free(mmap_event);
|
|
|
|
out_free_comm:
|
|
|
|
free(comm_event);
|
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__synthesize_threads(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
perf_event__handler_t process,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-10-27 04:23:18 +07:00
|
|
|
{
|
|
|
|
DIR *proc;
|
|
|
|
struct dirent dirent, *next;
|
2011-01-29 23:01:45 +07:00
|
|
|
union perf_event *comm_event, *mmap_event;
|
2010-12-02 19:25:28 +07:00
|
|
|
int err = -1;
|
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
comm_event = malloc(sizeof(comm_event->comm) + machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
if (comm_event == NULL)
|
|
|
|
goto out;
|
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
mmap_event = malloc(sizeof(mmap_event->mmap) + machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
if (mmap_event == NULL)
|
|
|
|
goto out_free_comm;
|
2009-10-27 04:23:18 +07:00
|
|
|
|
|
|
|
proc = opendir("/proc");
|
2010-12-02 19:25:28 +07:00
|
|
|
if (proc == NULL)
|
|
|
|
goto out_free_mmap;
|
2009-10-27 04:23:18 +07:00
|
|
|
|
|
|
|
while (!readdir_r(proc, &dirent, &next) && next) {
|
|
|
|
char *end;
|
|
|
|
pid_t pid = strtol(dirent.d_name, &end, 10);
|
|
|
|
|
|
|
|
if (*end) /* only interested in proper numerical dirents */
|
|
|
|
continue;
|
|
|
|
|
2010-12-02 19:25:28 +07:00
|
|
|
__event__synthesize_thread(comm_event, mmap_event, pid,
|
2011-11-28 17:30:20 +07:00
|
|
|
process, tool, machine);
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
closedir(proc);
|
2010-12-02 19:25:28 +07:00
|
|
|
err = 0;
|
|
|
|
out_free_mmap:
|
|
|
|
free(mmap_event);
|
|
|
|
out_free_comm:
|
|
|
|
free(comm_event);
|
|
|
|
out:
|
|
|
|
return err;
|
2009-10-27 04:23:18 +07:00
|
|
|
}
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2010-01-06 01:50:31 +07:00
|
|
|
struct process_symbol_args {
|
|
|
|
const char *name;
|
|
|
|
u64 start;
|
|
|
|
};
|
|
|
|
|
2010-12-22 10:08:36 +07:00
|
|
|
static int find_symbol_cb(void *arg, const char *name, char type,
|
|
|
|
u64 start, u64 end __used)
|
2010-01-06 01:50:31 +07:00
|
|
|
{
|
|
|
|
struct process_symbol_args *args = arg;
|
|
|
|
|
2010-01-16 03:08:27 +07:00
|
|
|
/*
|
|
|
|
* Must be a function or at least an alias, as in PARISC64, where "_text" is
|
|
|
|
* an 'A' to the same address as "_stext".
|
|
|
|
*/
|
|
|
|
if (!(symbol_type__is_a(type, MAP__FUNCTION) ||
|
|
|
|
type == 'A') || strcmp(name, args->name))
|
2010-01-06 01:50:31 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
args->start = start;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
perf_event__handler_t process,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct machine *machine,
|
|
|
|
const char *symbol_name)
|
2010-01-06 01:50:31 +07:00
|
|
|
{
|
|
|
|
size_t size;
|
2010-04-19 12:32:50 +07:00
|
|
|
const char *filename, *mmap_name;
|
|
|
|
char path[PATH_MAX];
|
|
|
|
char name_buff[PATH_MAX];
|
|
|
|
struct map *map;
|
2010-12-02 19:25:28 +07:00
|
|
|
int err;
|
2010-01-06 01:50:31 +07:00
|
|
|
/*
|
|
|
|
* We should get this from /sys/kernel/sections/.text, but till that is
|
|
|
|
* available use this, and after it is use this as a fallback for older
|
|
|
|
* kernels.
|
|
|
|
*/
|
|
|
|
struct process_symbol_args args = { .name = symbol_name, };
|
2011-01-29 23:01:45 +07:00
|
|
|
union perf_event *event = zalloc((sizeof(event->mmap) +
|
2011-11-28 16:56:39 +07:00
|
|
|
machine->id_hdr_size));
|
2010-12-02 19:25:28 +07:00
|
|
|
if (event == NULL) {
|
|
|
|
pr_debug("Not enough memory synthesizing mmap event "
|
|
|
|
"for kernel modules\n");
|
|
|
|
return -1;
|
|
|
|
}
|
2010-01-06 01:50:31 +07:00
|
|
|
|
2010-04-28 07:19:05 +07:00
|
|
|
mmap_name = machine__mmap_name(machine, name_buff, sizeof(name_buff));
|
2010-04-28 07:17:50 +07:00
|
|
|
if (machine__is_host(machine)) {
|
2010-04-19 12:32:50 +07:00
|
|
|
/*
|
|
|
|
* kernel uses PERF_RECORD_MISC_USER for user space maps,
|
|
|
|
* see kernel/perf_event.c __perf_event_mmap
|
|
|
|
*/
|
2010-12-02 19:25:28 +07:00
|
|
|
event->header.misc = PERF_RECORD_MISC_KERNEL;
|
2010-04-19 12:32:50 +07:00
|
|
|
filename = "/proc/kallsyms";
|
|
|
|
} else {
|
2010-12-02 19:25:28 +07:00
|
|
|
event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
|
2010-04-28 07:17:50 +07:00
|
|
|
if (machine__is_default_guest(machine))
|
2010-04-19 12:32:50 +07:00
|
|
|
filename = (char *) symbol_conf.default_guest_kallsyms;
|
|
|
|
else {
|
2010-04-28 07:17:50 +07:00
|
|
|
sprintf(path, "%s/proc/kallsyms", machine->root_dir);
|
2010-04-19 12:32:50 +07:00
|
|
|
filename = path;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kallsyms__parse(filename, &args, find_symbol_cb) <= 0)
|
2010-01-06 01:50:31 +07:00
|
|
|
return -ENOENT;
|
|
|
|
|
2010-04-28 07:17:50 +07:00
|
|
|
map = machine->vmlinux_maps[MAP__FUNCTION];
|
2010-12-02 19:25:28 +07:00
|
|
|
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
|
2010-04-19 12:32:50 +07:00
|
|
|
"%s%s", mmap_name, symbol_name) + 1;
|
2010-01-06 01:50:31 +07:00
|
|
|
size = ALIGN(size, sizeof(u64));
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.header.type = PERF_RECORD_MMAP;
|
|
|
|
event->mmap.header.size = (sizeof(event->mmap) -
|
2011-11-28 16:56:39 +07:00
|
|
|
(sizeof(event->mmap.filename) - size) + machine->id_hdr_size);
|
2010-12-02 19:25:28 +07:00
|
|
|
event->mmap.pgoff = args.start;
|
|
|
|
event->mmap.start = map->start;
|
|
|
|
event->mmap.len = map->end - event->mmap.start;
|
|
|
|
event->mmap.pid = machine->pid;
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
err = process(tool, event, &synth_sample, machine);
|
2010-12-02 19:25:28 +07:00
|
|
|
free(event);
|
|
|
|
|
|
|
|
return err;
|
2010-01-06 01:50:31 +07:00
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__process_comm(struct perf_tool *tool __used,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct perf_sample *sample __used,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-11-28 01:29:22 +07:00
|
|
|
{
|
2011-11-28 16:56:39 +07:00
|
|
|
struct thread *thread = machine__findnew_thread(machine, event->comm.tid);
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
dump_printf(": %s:%d\n", event->comm.comm, event->comm.tid);
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2011-03-05 00:51:33 +07:00
|
|
|
if (thread == NULL || thread__set_comm(thread, event->comm.comm)) {
|
2009-11-28 01:29:22 +07:00
|
|
|
dump_printf("problem processing PERF_RECORD_COMM, skipping event.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__process_lost(struct perf_tool *tool __used,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct perf_sample *sample __used,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine __used)
|
2009-11-28 01:29:22 +07:00
|
|
|
{
|
2011-01-23 05:37:02 +07:00
|
|
|
dump_printf(": id:%" PRIu64 ": lost:%" PRIu64 "\n",
|
2011-01-29 23:01:45 +07:00
|
|
|
event->lost.id, event->lost.lost);
|
2009-11-28 01:29:22 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
static void perf_event__set_kernel_mmap_len(union perf_event *event,
|
|
|
|
struct map **maps)
|
2010-04-19 12:32:50 +07:00
|
|
|
{
|
2011-01-29 23:01:45 +07:00
|
|
|
maps[MAP__FUNCTION]->start = event->mmap.start;
|
|
|
|
maps[MAP__FUNCTION]->end = event->mmap.start + event->mmap.len;
|
2010-04-19 12:32:50 +07:00
|
|
|
/*
|
|
|
|
* Be a bit paranoid here, some perf.data file came with
|
|
|
|
* a zero sized synthesized MMAP event for the kernel.
|
|
|
|
*/
|
|
|
|
if (maps[MAP__FUNCTION]->end == 0)
|
2010-11-25 11:12:53 +07:00
|
|
|
maps[MAP__FUNCTION]->end = ~0ULL;
|
2010-04-19 12:32:50 +07:00
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
static int perf_event__process_kernel_mmap(struct perf_tool *tool __used,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-11-28 01:29:22 +07:00
|
|
|
{
|
2010-01-06 01:50:31 +07:00
|
|
|
struct map *map;
|
2010-04-19 12:32:50 +07:00
|
|
|
char kmmap_prefix[PATH_MAX];
|
|
|
|
enum dso_kernel_type kernel_type;
|
|
|
|
bool is_kernel_mmap;
|
|
|
|
|
2010-04-28 07:19:05 +07:00
|
|
|
machine__mmap_name(machine, kmmap_prefix, sizeof(kmmap_prefix));
|
2010-04-28 07:17:50 +07:00
|
|
|
if (machine__is_host(machine))
|
2010-04-19 12:32:50 +07:00
|
|
|
kernel_type = DSO_TYPE_KERNEL;
|
|
|
|
else
|
|
|
|
kernel_type = DSO_TYPE_GUEST_KERNEL;
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
is_kernel_mmap = memcmp(event->mmap.filename,
|
2010-04-19 12:32:50 +07:00
|
|
|
kmmap_prefix,
|
|
|
|
strlen(kmmap_prefix)) == 0;
|
2011-01-29 23:01:45 +07:00
|
|
|
if (event->mmap.filename[0] == '/' ||
|
|
|
|
(!is_kernel_mmap && event->mmap.filename[0] == '[')) {
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
|
2010-04-19 12:32:50 +07:00
|
|
|
char short_module_name[1024];
|
|
|
|
char *name, *dot;
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
if (event->mmap.filename[0] == '/') {
|
|
|
|
name = strrchr(event->mmap.filename, '/');
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
if (name == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
++name; /* skip / */
|
|
|
|
dot = strrchr(name, '.');
|
|
|
|
if (dot == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
snprintf(short_module_name, sizeof(short_module_name),
|
2010-04-19 12:32:50 +07:00
|
|
|
"[%.*s]", (int)(dot - name), name);
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
strxfrchar(short_module_name, '-', '_');
|
2010-04-19 12:32:50 +07:00
|
|
|
} else
|
2011-01-29 23:01:45 +07:00
|
|
|
strcpy(short_module_name, event->mmap.filename);
|
2010-04-19 12:32:50 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
map = machine__new_module(machine, event->mmap.start,
|
|
|
|
event->mmap.filename);
|
2010-04-19 12:32:50 +07:00
|
|
|
if (map == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
name = strdup(short_module_name);
|
|
|
|
if (name == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
map->dso->short_name = name;
|
2010-07-30 01:11:30 +07:00
|
|
|
map->dso->sname_alloc = 1;
|
2011-01-29 23:01:45 +07:00
|
|
|
map->end = map->start + event->mmap.len;
|
2010-04-19 12:32:50 +07:00
|
|
|
} else if (is_kernel_mmap) {
|
2011-01-29 23:01:45 +07:00
|
|
|
const char *symbol_name = (event->mmap.filename +
|
2010-04-19 12:32:50 +07:00
|
|
|
strlen(kmmap_prefix));
|
|
|
|
/*
|
|
|
|
* Should be there already, from the build-id table in
|
|
|
|
* the header.
|
|
|
|
*/
|
2010-04-28 07:17:50 +07:00
|
|
|
struct dso *kernel = __dsos__findnew(&machine->kernel_dsos,
|
|
|
|
kmmap_prefix);
|
2010-04-19 12:32:50 +07:00
|
|
|
if (kernel == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
kernel->kernel = kernel_type;
|
2010-04-28 07:20:43 +07:00
|
|
|
if (__machine__create_kernel_maps(machine, kernel) < 0)
|
2010-04-19 12:32:50 +07:00
|
|
|
goto out_problem;
|
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
perf_event__set_kernel_mmap_len(event, machine->vmlinux_maps);
|
perf symbols: Handle /proc/sys/kernel/kptr_restrict
Perf uses /proc/modules to figure out where kernel modules are loaded.
With the advent of kptr_restrict, non root users get zeroes for all module
start addresses.
So check if kptr_restrict is non zero and don't generate the syntethic
PERF_RECORD_MMAP events for them.
Warn the user about it in perf record and in perf report.
In perf report the reference relocation symbol being zero means that
kptr_restrict was set, thus /proc/kallsyms has only zeroed addresses, so don't
use it to fixup symbol addresses when using a valid kallsyms (in the buildid
cache) or vmlinux (in the vmlinux path) build-id located automatically or
specified by the user.
Provide an explanation about it in 'perf report' if kernel samples were taken,
checking if a suitable vmlinux or kallsyms was found/specified.
Restricted /proc/kallsyms don't go to the buildid cache anymore.
Example:
[acme@emilia ~]$ perf record -F 100000 sleep 1
WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check
/proc/sys/kernel/kptr_restrict.
Samples in kernel functions may not be resolved if a suitable vmlinux file is
not found in the buildid cache or in the vmlinux path.
Samples in kernel modules won't be resolved at all.
If some relocation was applied (e.g. kexec) symbols may be misresolved even
with a suitable vmlinux or kallsyms file.
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.005 MB perf.data (~231 samples) ]
[acme@emilia ~]$
[acme@emilia ~]$ perf report --stdio
Kernel address maps (/proc/{kallsyms,modules}) were restricted,
check /proc/sys/kernel/kptr_restrict before running 'perf record'.
If some relocation was applied (e.g. kexec) symbols may be misresolved.
Samples in kernel modules can't be resolved as well.
# Events: 13 cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. .....................
#
20.24% sleep [kernel.kallsyms] [k] page_fault
20.04% sleep [kernel.kallsyms] [k] filemap_fault
19.78% sleep [kernel.kallsyms] [k] __lru_cache_add
19.69% sleep ld-2.12.so [.] memcpy
14.71% sleep [kernel.kallsyms] [k] dput
4.70% sleep [kernel.kallsyms] [k] flush_signal_handlers
0.73% sleep [kernel.kallsyms] [k] perf_event_comm
0.11% sleep [kernel.kallsyms] [k] native_write_msr_safe
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@emilia ~]$
This is because it found a suitable vmlinux (build-id checked) in
/lib/modules/2.6.39-rc7+/build/vmlinux (use -v in perf report to see the long
file name).
If we remove that file from the vmlinux path:
[root@emilia ~]# mv /lib/modules/2.6.39-rc7+/build/vmlinux \
/lib/modules/2.6.39-rc7+/build/vmlinux.OFF
[acme@emilia ~]$ perf report --stdio
[kernel.kallsyms] with build id 57298cdbe0131f6871667ec0eaab4804dcf6f562
not found, continuing without symbols
Kernel address maps (/proc/{kallsyms,modules}) were restricted, check
/proc/sys/kernel/kptr_restrict before running 'perf record'.
As no suitable kallsyms nor vmlinux was found, kernel samples can't be
resolved.
Samples in kernel modules can't be resolved as well.
# Events: 13 cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ......
#
80.31% sleep [kernel.kallsyms] [k] 0xffffffff8103425a
19.69% sleep ld-2.12.so [.] memcpy
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@emilia ~]$
Reported-by: Stephane Eranian <eranian@google.com>
Suggested-by: David Miller <davem@davemloft.net>
Cc: Dave Jones <davej@redhat.com>
Cc: David Miller <davem@davemloft.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Kees Cook <kees.cook@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Tom Zanussi <tzanussi@gmail.com>
Link: http://lkml.kernel.org/n/tip-mt512joaxxbhhp1odop04yit@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-05-26 19:53:51 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid using a zero address (kptr_restrict) for the ref reloc
|
|
|
|
* symbol. Effectively having zero here means that at record
|
|
|
|
* time /proc/sys/kernel/kptr_restrict was non zero.
|
|
|
|
*/
|
|
|
|
if (event->mmap.pgoff != 0) {
|
2011-11-28 16:56:39 +07:00
|
|
|
maps__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps,
|
|
|
|
symbol_name,
|
|
|
|
event->mmap.pgoff);
|
perf symbols: Handle /proc/sys/kernel/kptr_restrict
Perf uses /proc/modules to figure out where kernel modules are loaded.
With the advent of kptr_restrict, non root users get zeroes for all module
start addresses.
So check if kptr_restrict is non zero and don't generate the syntethic
PERF_RECORD_MMAP events for them.
Warn the user about it in perf record and in perf report.
In perf report the reference relocation symbol being zero means that
kptr_restrict was set, thus /proc/kallsyms has only zeroed addresses, so don't
use it to fixup symbol addresses when using a valid kallsyms (in the buildid
cache) or vmlinux (in the vmlinux path) build-id located automatically or
specified by the user.
Provide an explanation about it in 'perf report' if kernel samples were taken,
checking if a suitable vmlinux or kallsyms was found/specified.
Restricted /proc/kallsyms don't go to the buildid cache anymore.
Example:
[acme@emilia ~]$ perf record -F 100000 sleep 1
WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check
/proc/sys/kernel/kptr_restrict.
Samples in kernel functions may not be resolved if a suitable vmlinux file is
not found in the buildid cache or in the vmlinux path.
Samples in kernel modules won't be resolved at all.
If some relocation was applied (e.g. kexec) symbols may be misresolved even
with a suitable vmlinux or kallsyms file.
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.005 MB perf.data (~231 samples) ]
[acme@emilia ~]$
[acme@emilia ~]$ perf report --stdio
Kernel address maps (/proc/{kallsyms,modules}) were restricted,
check /proc/sys/kernel/kptr_restrict before running 'perf record'.
If some relocation was applied (e.g. kexec) symbols may be misresolved.
Samples in kernel modules can't be resolved as well.
# Events: 13 cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. .....................
#
20.24% sleep [kernel.kallsyms] [k] page_fault
20.04% sleep [kernel.kallsyms] [k] filemap_fault
19.78% sleep [kernel.kallsyms] [k] __lru_cache_add
19.69% sleep ld-2.12.so [.] memcpy
14.71% sleep [kernel.kallsyms] [k] dput
4.70% sleep [kernel.kallsyms] [k] flush_signal_handlers
0.73% sleep [kernel.kallsyms] [k] perf_event_comm
0.11% sleep [kernel.kallsyms] [k] native_write_msr_safe
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@emilia ~]$
This is because it found a suitable vmlinux (build-id checked) in
/lib/modules/2.6.39-rc7+/build/vmlinux (use -v in perf report to see the long
file name).
If we remove that file from the vmlinux path:
[root@emilia ~]# mv /lib/modules/2.6.39-rc7+/build/vmlinux \
/lib/modules/2.6.39-rc7+/build/vmlinux.OFF
[acme@emilia ~]$ perf report --stdio
[kernel.kallsyms] with build id 57298cdbe0131f6871667ec0eaab4804dcf6f562
not found, continuing without symbols
Kernel address maps (/proc/{kallsyms,modules}) were restricted, check
/proc/sys/kernel/kptr_restrict before running 'perf record'.
As no suitable kallsyms nor vmlinux was found, kernel samples can't be
resolved.
Samples in kernel modules can't be resolved as well.
# Events: 13 cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ......
#
80.31% sleep [kernel.kallsyms] [k] 0xffffffff8103425a
19.69% sleep ld-2.12.so [.] memcpy
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@emilia ~]$
Reported-by: Stephane Eranian <eranian@google.com>
Suggested-by: David Miller <davem@davemloft.net>
Cc: Dave Jones <davej@redhat.com>
Cc: David Miller <davem@davemloft.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Kees Cook <kees.cook@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Tom Zanussi <tzanussi@gmail.com>
Link: http://lkml.kernel.org/n/tip-mt512joaxxbhhp1odop04yit@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-05-26 19:53:51 +07:00
|
|
|
}
|
|
|
|
|
2010-04-28 07:17:50 +07:00
|
|
|
if (machine__is_default_guest(machine)) {
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
/*
|
2010-04-19 12:32:50 +07:00
|
|
|
* preload dso of guest kernel and modules
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
*/
|
2010-04-28 07:17:50 +07:00
|
|
|
dso__load(kernel, machine->vmlinux_maps[MAP__FUNCTION],
|
|
|
|
NULL);
|
2010-04-19 12:32:50 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
out_problem:
|
|
|
|
return -1;
|
|
|
|
}
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__process_mmap(struct perf_tool *tool,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct perf_sample *sample __used,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2010-04-19 12:32:50 +07:00
|
|
|
{
|
|
|
|
struct thread *thread;
|
|
|
|
struct map *map;
|
2011-01-29 23:01:45 +07:00
|
|
|
u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
|
2010-04-19 12:32:50 +07:00
|
|
|
int ret = 0;
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
|
2011-01-23 05:37:02 +07:00
|
|
|
dump_printf(" %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64 "]: %s\n",
|
2011-01-29 23:01:45 +07:00
|
|
|
event->mmap.pid, event->mmap.tid, event->mmap.start,
|
|
|
|
event->mmap.len, event->mmap.pgoff, event->mmap.filename);
|
2010-04-19 12:32:50 +07:00
|
|
|
|
|
|
|
if (cpumode == PERF_RECORD_MISC_GUEST_KERNEL ||
|
|
|
|
cpumode == PERF_RECORD_MISC_KERNEL) {
|
2011-11-28 17:30:20 +07:00
|
|
|
ret = perf_event__process_kernel_mmap(tool, event, machine);
|
2010-04-19 12:32:50 +07:00
|
|
|
if (ret < 0)
|
|
|
|
goto out_problem;
|
2010-01-06 01:50:31 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
thread = machine__findnew_thread(machine, event->mmap.pid);
|
2010-07-31 04:31:28 +07:00
|
|
|
if (thread == NULL)
|
|
|
|
goto out_problem;
|
2011-01-29 23:01:45 +07:00
|
|
|
map = map__new(&machine->user_dsos, event->mmap.start,
|
|
|
|
event->mmap.len, event->mmap.pgoff,
|
|
|
|
event->mmap.pid, event->mmap.filename,
|
2010-07-27 22:40:02 +07:00
|
|
|
MAP__FUNCTION);
|
2010-07-31 04:31:28 +07:00
|
|
|
if (map == NULL)
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
thread__insert_map(thread, map);
|
|
|
|
return 0;
|
2009-11-28 01:29:22 +07:00
|
|
|
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 22:22:17 +07:00
|
|
|
out_problem:
|
|
|
|
dump_printf("problem processing PERF_RECORD_MMAP, skipping event.\n");
|
2009-11-28 01:29:22 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__process_task(struct perf_tool *tool __used,
|
2011-11-25 17:19:45 +07:00
|
|
|
union perf_event *event,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct perf_sample *sample __used,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine)
|
2009-11-28 01:29:22 +07:00
|
|
|
{
|
2011-11-28 16:56:39 +07:00
|
|
|
struct thread *thread = machine__findnew_thread(machine, event->fork.tid);
|
|
|
|
struct thread *parent = machine__findnew_thread(machine, event->fork.ptid);
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
dump_printf("(%d:%d):(%d:%d)\n", event->fork.pid, event->fork.tid,
|
|
|
|
event->fork.ppid, event->fork.ptid);
|
2009-11-28 01:29:22 +07:00
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
if (event->header.type == PERF_RECORD_EXIT) {
|
2011-11-28 16:56:39 +07:00
|
|
|
machine__remove_thread(machine, thread);
|
2009-11-28 01:29:22 +07:00
|
|
|
return 0;
|
2010-06-17 18:37:44 +07:00
|
|
|
}
|
2009-11-28 01:29:22 +07:00
|
|
|
|
|
|
|
if (thread == NULL || parent == NULL ||
|
|
|
|
thread__fork(thread, parent) < 0) {
|
|
|
|
dump_printf("problem processing PERF_RECORD_FORK, skipping event.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
|
2011-11-28 17:30:20 +07:00
|
|
|
int perf_event__process(struct perf_tool *tool, union perf_event *event,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct perf_sample *sample, struct machine *machine)
|
2010-08-02 19:38:51 +07:00
|
|
|
{
|
|
|
|
switch (event->header.type) {
|
|
|
|
case PERF_RECORD_COMM:
|
2011-11-28 17:30:20 +07:00
|
|
|
perf_event__process_comm(tool, event, sample, machine);
|
2010-08-02 19:38:51 +07:00
|
|
|
break;
|
|
|
|
case PERF_RECORD_MMAP:
|
2011-11-28 17:30:20 +07:00
|
|
|
perf_event__process_mmap(tool, event, sample, machine);
|
2010-08-02 19:38:51 +07:00
|
|
|
break;
|
|
|
|
case PERF_RECORD_FORK:
|
|
|
|
case PERF_RECORD_EXIT:
|
2011-11-28 17:30:20 +07:00
|
|
|
perf_event__process_task(tool, event, sample, machine);
|
2010-08-02 19:38:51 +07:00
|
|
|
break;
|
2011-01-29 18:04:40 +07:00
|
|
|
case PERF_RECORD_LOST:
|
2011-11-28 17:30:20 +07:00
|
|
|
perf_event__process_lost(tool, event, sample, machine);
|
2010-08-02 19:38:51 +07:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-01-15 08:45:29 +07:00
|
|
|
void thread__find_addr_map(struct thread *self,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine, u8 cpumode,
|
|
|
|
enum map_type type, u64 addr,
|
2010-01-15 08:45:29 +07:00
|
|
|
struct addr_location *al)
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
{
|
2009-12-11 23:50:36 +07:00
|
|
|
struct map_groups *mg = &self->mg;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
|
2009-12-11 23:50:36 +07:00
|
|
|
al->thread = self;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
al->addr = addr;
|
2010-04-19 12:32:50 +07:00
|
|
|
al->cpumode = cpumode;
|
|
|
|
al->filtered = false;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
if (machine == NULL) {
|
|
|
|
al->map = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-04-19 12:32:50 +07:00
|
|
|
if (cpumode == PERF_RECORD_MISC_KERNEL && perf_host) {
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
al->level = 'k';
|
2010-04-28 07:17:50 +07:00
|
|
|
mg = &machine->kmaps;
|
2010-04-19 12:32:50 +07:00
|
|
|
} else if (cpumode == PERF_RECORD_MISC_USER && perf_host) {
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
al->level = '.';
|
2010-04-19 12:32:50 +07:00
|
|
|
} else if (cpumode == PERF_RECORD_MISC_GUEST_KERNEL && perf_guest) {
|
|
|
|
al->level = 'g';
|
2010-04-28 07:17:50 +07:00
|
|
|
mg = &machine->kmaps;
|
2010-04-19 12:32:50 +07:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* 'u' means guest os user space.
|
|
|
|
* TODO: We don't support guest user space. Might support late.
|
|
|
|
*/
|
|
|
|
if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest)
|
|
|
|
al->level = 'u';
|
|
|
|
else
|
|
|
|
al->level = 'H';
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
al->map = NULL;
|
2010-04-19 12:32:50 +07:00
|
|
|
|
|
|
|
if ((cpumode == PERF_RECORD_MISC_GUEST_USER ||
|
|
|
|
cpumode == PERF_RECORD_MISC_GUEST_KERNEL) &&
|
|
|
|
!perf_guest)
|
|
|
|
al->filtered = true;
|
|
|
|
if ((cpumode == PERF_RECORD_MISC_USER ||
|
|
|
|
cpumode == PERF_RECORD_MISC_KERNEL) &&
|
|
|
|
!perf_host)
|
|
|
|
al->filtered = true;
|
|
|
|
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
try_again:
|
2009-12-11 23:50:36 +07:00
|
|
|
al->map = map_groups__find(mg, type, al->addr);
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
if (al->map == NULL) {
|
|
|
|
/*
|
|
|
|
* If this is outside of all known maps, and is a negative
|
|
|
|
* address, try to look it up in the kernel dso, as it might be
|
|
|
|
* a vsyscall or vdso (which executes in user-mode).
|
|
|
|
*
|
|
|
|
* XXX This is nasty, we should have a symbol list in the
|
|
|
|
* "[vdso]" dso, but for now lets use the old trick of looking
|
|
|
|
* in the whole kernel symbol list.
|
|
|
|
*/
|
2010-04-19 12:32:50 +07:00
|
|
|
if ((long long)al->addr < 0 &&
|
2011-03-24 11:36:56 +07:00
|
|
|
cpumode == PERF_RECORD_MISC_USER &&
|
2010-04-28 07:17:50 +07:00
|
|
|
machine && mg != &machine->kmaps) {
|
|
|
|
mg = &machine->kmaps;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
goto try_again;
|
|
|
|
}
|
2010-01-15 08:45:29 +07:00
|
|
|
} else
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
al->addr = al->map->map_ip(al->map, al->addr);
|
2010-01-15 08:45:29 +07:00
|
|
|
}
|
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
void thread__find_addr_location(struct thread *thread, struct machine *machine,
|
|
|
|
u8 cpumode, enum map_type type, u64 addr,
|
2010-01-15 08:45:29 +07:00
|
|
|
struct addr_location *al,
|
|
|
|
symbol_filter_t filter)
|
|
|
|
{
|
2011-11-28 16:56:39 +07:00
|
|
|
thread__find_addr_map(thread, machine, cpumode, type, addr, al);
|
2010-01-15 08:45:29 +07:00
|
|
|
if (al->map != NULL)
|
2010-02-04 01:52:00 +07:00
|
|
|
al->sym = map__find_symbol(al->map, al->addr, filter);
|
2010-01-15 08:45:29 +07:00
|
|
|
else
|
|
|
|
al->sym = NULL;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
}
|
|
|
|
|
2011-01-29 23:01:45 +07:00
|
|
|
int perf_event__preprocess_sample(const union perf_event *event,
|
2011-11-28 16:56:39 +07:00
|
|
|
struct machine *machine,
|
2011-01-29 23:01:45 +07:00
|
|
|
struct addr_location *al,
|
|
|
|
struct perf_sample *sample,
|
|
|
|
symbol_filter_t filter)
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
{
|
2011-01-29 23:01:45 +07:00
|
|
|
u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
|
2011-11-28 16:56:39 +07:00
|
|
|
struct thread *thread = machine__findnew_thread(machine, event->ip.pid);
|
2010-06-04 18:02:07 +07:00
|
|
|
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
if (thread == NULL)
|
|
|
|
return -1;
|
|
|
|
|
2009-12-16 05:04:41 +07:00
|
|
|
if (symbol_conf.comm_list &&
|
|
|
|
!strlist__has_entry(symbol_conf.comm_list, thread->comm))
|
|
|
|
goto out_filtered;
|
|
|
|
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
dump_printf(" ... thread: %s:%d\n", thread->comm, thread->pid);
|
2010-05-10 05:57:08 +07:00
|
|
|
/*
|
2011-11-28 16:56:39 +07:00
|
|
|
* Have we already created the kernel maps for this machine?
|
2010-05-10 05:57:08 +07:00
|
|
|
*
|
|
|
|
* This should have happened earlier, when we processed the kernel MMAP
|
|
|
|
* events, but for older perf.data files there was no such thing, so do
|
|
|
|
* it now.
|
|
|
|
*/
|
|
|
|
if (cpumode == PERF_RECORD_MISC_KERNEL &&
|
2011-11-28 16:56:39 +07:00
|
|
|
machine->vmlinux_maps[MAP__FUNCTION] == NULL)
|
|
|
|
machine__create_kernel_maps(machine);
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
|
2011-11-28 16:56:39 +07:00
|
|
|
thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
|
|
|
|
event->ip.ip, al);
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
dump_printf(" ...... dso: %s\n",
|
|
|
|
al->map ? al->map->dso->long_name :
|
|
|
|
al->level == 'H' ? "[hypervisor]" : "<not found>");
|
2010-03-25 02:40:15 +07:00
|
|
|
al->sym = NULL;
|
2011-01-29 22:02:00 +07:00
|
|
|
al->cpu = sample->cpu;
|
2010-03-25 02:40:15 +07:00
|
|
|
|
|
|
|
if (al->map) {
|
|
|
|
if (symbol_conf.dso_list &&
|
|
|
|
(!al->map || !al->map->dso ||
|
|
|
|
!(strlist__has_entry(symbol_conf.dso_list,
|
|
|
|
al->map->dso->short_name) ||
|
|
|
|
(al->map->dso->short_name != al->map->dso->long_name &&
|
|
|
|
strlist__has_entry(symbol_conf.dso_list,
|
|
|
|
al->map->dso->long_name)))))
|
|
|
|
goto out_filtered;
|
|
|
|
|
|
|
|
al->sym = map__find_symbol(al->map, al->addr, filter);
|
|
|
|
}
|
2009-12-16 05:04:41 +07:00
|
|
|
|
|
|
|
if (symbol_conf.sym_list && al->sym &&
|
|
|
|
!strlist__has_entry(symbol_conf.sym_list, al->sym->name))
|
|
|
|
goto out_filtered;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_filtered:
|
|
|
|
al->filtered = true;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-28 01:29:23 +07:00
|
|
|
return 0;
|
|
|
|
}
|