2009-10-27 05:23:18 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include "event.h"
|
|
|
|
#include "debug.h"
|
2009-12-14 05:50:27 +08:00
|
|
|
#include "session.h"
|
2009-12-16 06:04:41 +08:00
|
|
|
#include "sort.h"
|
2009-10-27 05:23:18 +08:00
|
|
|
#include "string.h"
|
2009-12-16 06:04:41 +08:00
|
|
|
#include "strlist.h"
|
2009-11-28 02:29:22 +08:00
|
|
|
#include "thread.h"
|
2009-10-27 05:23:18 +08:00
|
|
|
|
2010-05-14 21:36:42 +08:00
|
|
|
const char *event__name[] = {
|
|
|
|
[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",
|
|
|
|
};
|
|
|
|
|
2009-10-27 05:23:18 +08:00
|
|
|
static pid_t event__synthesize_comm(pid_t pid, int full,
|
2010-01-08 05:59:40 +08:00
|
|
|
event__handler_t process,
|
2009-12-14 05:50:24 +08:00
|
|
|
struct perf_session *session)
|
2009-10-27 05:23:18 +08:00
|
|
|
{
|
|
|
|
event_t ev;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&ev.comm, 0, sizeof(ev.comm));
|
|
|
|
while (!ev.comm.comm[0] || !ev.comm.pid) {
|
|
|
|
if (fgets(bf, sizeof(bf), fp) == NULL)
|
|
|
|
goto out_failure;
|
|
|
|
|
|
|
|
if (memcmp(bf, "Name:", 5) == 0) {
|
|
|
|
char *name = bf + 5;
|
|
|
|
while (*name && isspace(*name))
|
|
|
|
++name;
|
|
|
|
size = strlen(name) - 1;
|
|
|
|
memcpy(ev.comm.comm, name, size++);
|
|
|
|
} else if (memcmp(bf, "Tgid:", 5) == 0) {
|
|
|
|
char *tgids = bf + 5;
|
|
|
|
while (*tgids && isspace(*tgids))
|
|
|
|
++tgids;
|
|
|
|
tgid = ev.comm.pid = atoi(tgids);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ev.comm.header.type = PERF_RECORD_COMM;
|
|
|
|
size = ALIGN(size, sizeof(u64));
|
|
|
|
ev.comm.header.size = sizeof(ev.comm) - (sizeof(ev.comm.comm) - size);
|
|
|
|
|
|
|
|
if (!full) {
|
|
|
|
ev.comm.tid = pid;
|
|
|
|
|
2009-12-14 05:50:24 +08:00
|
|
|
process(&ev, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
goto out_fclose;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
ev.comm.tid = pid;
|
|
|
|
|
2009-12-14 05:50:24 +08:00
|
|
|
process(&ev, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
}
|
|
|
|
closedir(tasks);
|
|
|
|
|
|
|
|
out_fclose:
|
|
|
|
fclose(fp);
|
|
|
|
return tgid;
|
|
|
|
|
|
|
|
out_failure:
|
|
|
|
pr_warning("couldn't get COMM and pgid, malformed %s\n", filename);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int event__synthesize_mmap_events(pid_t pid, pid_t tgid,
|
2010-01-08 05:59:40 +08:00
|
|
|
event__handler_t process,
|
2009-12-14 05:50:24 +08:00
|
|
|
struct perf_session *session)
|
2009-10-27 05:23:18 +08: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;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
char bf[BUFSIZ], *pbf = bf;
|
|
|
|
event_t ev = {
|
2010-01-15 09:45:28 +08:00
|
|
|
.header = {
|
|
|
|
.type = PERF_RECORD_MMAP,
|
2010-04-19 13:32:50 +08:00
|
|
|
/*
|
|
|
|
* Just like the kernel, see __perf_event_mmap
|
|
|
|
* in kernel/perf_event.c
|
|
|
|
*/
|
|
|
|
.misc = PERF_RECORD_MISC_USER,
|
2010-01-15 09:45:28 +08:00
|
|
|
},
|
2009-10-27 05:23:18 +08:00
|
|
|
};
|
|
|
|
int n;
|
|
|
|
size_t size;
|
|
|
|
if (fgets(bf, sizeof(bf), fp) == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* 00400000-0040c000 r-xp 00000000 fd:01 41038 /bin/cat */
|
|
|
|
n = hex2u64(pbf, &ev.mmap.start);
|
|
|
|
if (n < 0)
|
|
|
|
continue;
|
|
|
|
pbf += n + 1;
|
|
|
|
n = hex2u64(pbf, &ev.mmap.len);
|
|
|
|
if (n < 0)
|
|
|
|
continue;
|
|
|
|
pbf += n + 3;
|
|
|
|
if (*pbf == 'x') { /* vm_exec */
|
|
|
|
char *execname = strchr(bf, '/');
|
|
|
|
|
|
|
|
/* Catch VDSO */
|
|
|
|
if (execname == NULL)
|
|
|
|
execname = strstr(bf, "[vdso]");
|
|
|
|
|
|
|
|
if (execname == NULL)
|
|
|
|
continue;
|
|
|
|
|
2010-04-03 19:53:31 +08:00
|
|
|
pbf += 3;
|
2010-08-03 19:48:35 +08:00
|
|
|
n = hex2u64(pbf, &ev.mmap.pgoff);
|
2010-04-03 19:53:31 +08:00
|
|
|
|
2009-10-27 05:23:18 +08:00
|
|
|
size = strlen(execname);
|
|
|
|
execname[size - 1] = '\0'; /* Remove \n */
|
|
|
|
memcpy(ev.mmap.filename, execname, size);
|
|
|
|
size = ALIGN(size, sizeof(u64));
|
|
|
|
ev.mmap.len -= ev.mmap.start;
|
|
|
|
ev.mmap.header.size = (sizeof(ev.mmap) -
|
|
|
|
(sizeof(ev.mmap.filename) - size));
|
|
|
|
ev.mmap.pid = tgid;
|
|
|
|
ev.mmap.tid = pid;
|
|
|
|
|
2009-12-14 05:50:24 +08:00
|
|
|
process(&ev, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fclose(fp);
|
|
|
|
return 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 23:22:17 +08:00
|
|
|
int event__synthesize_modules(event__handler_t process,
|
2010-04-19 13:32:50 +08:00
|
|
|
struct perf_session *session,
|
2010-04-28 08:17:50 +08: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 23:22:17 +08:00
|
|
|
{
|
|
|
|
struct rb_node *nd;
|
2010-04-28 08:17:50 +08:00
|
|
|
struct map_groups *kmaps = &machine->kmaps;
|
2010-04-19 13:32:50 +08:00
|
|
|
u16 misc;
|
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 23:22:17 +08:00
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
/*
|
|
|
|
* kernel uses 0 for user space maps, see kernel/perf_event.c
|
|
|
|
* __perf_event_mmap
|
|
|
|
*/
|
2010-04-28 08:17:50 +08:00
|
|
|
if (machine__is_host(machine))
|
2010-04-19 13:32:50 +08:00
|
|
|
misc = PERF_RECORD_MISC_KERNEL;
|
|
|
|
else
|
|
|
|
misc = PERF_RECORD_MISC_GUEST_KERNEL;
|
|
|
|
|
|
|
|
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 23:22:17 +08:00
|
|
|
nd; nd = rb_next(nd)) {
|
|
|
|
event_t ev;
|
|
|
|
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));
|
|
|
|
memset(&ev, 0, sizeof(ev));
|
2010-04-19 13:32:50 +08:00
|
|
|
ev.mmap.header.misc = misc;
|
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 23:22:17 +08:00
|
|
|
ev.mmap.header.type = PERF_RECORD_MMAP;
|
|
|
|
ev.mmap.header.size = (sizeof(ev.mmap) -
|
|
|
|
(sizeof(ev.mmap.filename) - size));
|
|
|
|
ev.mmap.start = pos->start;
|
|
|
|
ev.mmap.len = pos->end - pos->start;
|
2010-04-28 08:17:50 +08:00
|
|
|
ev.mmap.pid = machine->pid;
|
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 23:22:17 +08:00
|
|
|
|
|
|
|
memcpy(ev.mmap.filename, pos->dso->long_name,
|
|
|
|
pos->dso->long_name_len + 1);
|
|
|
|
process(&ev, session);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-01-08 05:59:40 +08:00
|
|
|
int event__synthesize_thread(pid_t pid, event__handler_t process,
|
2009-12-14 05:50:24 +08:00
|
|
|
struct perf_session *session)
|
2009-10-27 05:23:18 +08:00
|
|
|
{
|
2009-12-14 05:50:24 +08:00
|
|
|
pid_t tgid = event__synthesize_comm(pid, 1, process, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
if (tgid == -1)
|
|
|
|
return -1;
|
2009-12-14 05:50:24 +08:00
|
|
|
return event__synthesize_mmap_events(pid, tgid, process, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
}
|
|
|
|
|
2010-01-08 05:59:40 +08:00
|
|
|
void event__synthesize_threads(event__handler_t process,
|
2009-12-14 05:50:24 +08:00
|
|
|
struct perf_session *session)
|
2009-10-27 05:23:18 +08:00
|
|
|
{
|
|
|
|
DIR *proc;
|
|
|
|
struct dirent dirent, *next;
|
|
|
|
|
|
|
|
proc = opendir("/proc");
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2009-12-14 05:50:24 +08:00
|
|
|
event__synthesize_thread(pid, process, session);
|
2009-10-27 05:23:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
closedir(proc);
|
|
|
|
}
|
2009-11-28 02:29:22 +08:00
|
|
|
|
2010-01-06 02:50:31 +08:00
|
|
|
struct process_symbol_args {
|
|
|
|
const char *name;
|
|
|
|
u64 start;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int find_symbol_cb(void *arg, const char *name, char type, u64 start)
|
|
|
|
{
|
|
|
|
struct process_symbol_args *args = arg;
|
|
|
|
|
2010-01-16 04:08:27 +08: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 02:50:31 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
args->start = start;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2010-01-08 05:59:40 +08:00
|
|
|
int event__synthesize_kernel_mmap(event__handler_t process,
|
2010-01-06 02:50:31 +08:00
|
|
|
struct perf_session *session,
|
2010-04-28 08:17:50 +08:00
|
|
|
struct machine *machine,
|
2010-01-06 02:50:31 +08:00
|
|
|
const char *symbol_name)
|
|
|
|
{
|
|
|
|
size_t size;
|
2010-04-19 13:32:50 +08:00
|
|
|
const char *filename, *mmap_name;
|
|
|
|
char path[PATH_MAX];
|
|
|
|
char name_buff[PATH_MAX];
|
|
|
|
struct map *map;
|
|
|
|
|
2010-01-06 02:50:31 +08:00
|
|
|
event_t ev = {
|
2010-01-15 09:45:28 +08:00
|
|
|
.header = {
|
|
|
|
.type = PERF_RECORD_MMAP,
|
|
|
|
},
|
2010-01-06 02:50:31 +08: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, };
|
|
|
|
|
2010-04-28 08:19:05 +08:00
|
|
|
mmap_name = machine__mmap_name(machine, name_buff, sizeof(name_buff));
|
2010-04-28 08:17:50 +08:00
|
|
|
if (machine__is_host(machine)) {
|
2010-04-19 13:32:50 +08:00
|
|
|
/*
|
|
|
|
* kernel uses PERF_RECORD_MISC_USER for user space maps,
|
|
|
|
* see kernel/perf_event.c __perf_event_mmap
|
|
|
|
*/
|
|
|
|
ev.header.misc = PERF_RECORD_MISC_KERNEL;
|
|
|
|
filename = "/proc/kallsyms";
|
|
|
|
} else {
|
|
|
|
ev.header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
|
2010-04-28 08:17:50 +08:00
|
|
|
if (machine__is_default_guest(machine))
|
2010-04-19 13:32:50 +08:00
|
|
|
filename = (char *) symbol_conf.default_guest_kallsyms;
|
|
|
|
else {
|
2010-04-28 08:17:50 +08:00
|
|
|
sprintf(path, "%s/proc/kallsyms", machine->root_dir);
|
2010-04-19 13:32:50 +08:00
|
|
|
filename = path;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kallsyms__parse(filename, &args, find_symbol_cb) <= 0)
|
2010-01-06 02:50:31 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
2010-04-28 08:17:50 +08:00
|
|
|
map = machine->vmlinux_maps[MAP__FUNCTION];
|
2010-01-06 02:50:31 +08:00
|
|
|
size = snprintf(ev.mmap.filename, sizeof(ev.mmap.filename),
|
2010-04-19 13:32:50 +08:00
|
|
|
"%s%s", mmap_name, symbol_name) + 1;
|
2010-01-06 02:50:31 +08:00
|
|
|
size = ALIGN(size, sizeof(u64));
|
2010-04-19 13:32:50 +08:00
|
|
|
ev.mmap.header.size = (sizeof(ev.mmap) -
|
|
|
|
(sizeof(ev.mmap.filename) - size));
|
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 23:22:17 +08:00
|
|
|
ev.mmap.pgoff = args.start;
|
2010-04-19 13:32:50 +08:00
|
|
|
ev.mmap.start = map->start;
|
|
|
|
ev.mmap.len = map->end - ev.mmap.start;
|
2010-04-28 08:17:50 +08:00
|
|
|
ev.mmap.pid = machine->pid;
|
2010-01-06 02:50:31 +08:00
|
|
|
|
|
|
|
return process(&ev, session);
|
|
|
|
}
|
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
static void thread__comm_adjust(struct thread *self, struct hists *hists)
|
2009-12-16 06:04:42 +08:00
|
|
|
{
|
|
|
|
char *comm = self->comm;
|
|
|
|
|
|
|
|
if (!symbol_conf.col_width_list_str && !symbol_conf.field_sep &&
|
|
|
|
(!symbol_conf.comm_list ||
|
|
|
|
strlist__has_entry(symbol_conf.comm_list, comm))) {
|
2010-07-21 01:42:52 +08:00
|
|
|
u16 slen = strlen(comm);
|
2009-12-16 06:04:42 +08:00
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
if (hists__new_col_len(hists, HISTC_COMM, slen))
|
|
|
|
hists__set_col_len(hists, HISTC_THREAD, slen + 6);
|
2009-12-16 06:04:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
static int thread__set_comm_adjust(struct thread *self, const char *comm,
|
|
|
|
struct hists *hists)
|
2009-12-16 06:04:42 +08:00
|
|
|
{
|
|
|
|
int ret = thread__set_comm(self, comm);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
thread__comm_adjust(self, hists);
|
2009-12-16 06:04:42 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-14 05:50:28 +08:00
|
|
|
int event__process_comm(event_t *self, struct perf_session *session)
|
2009-11-28 02:29:22 +08:00
|
|
|
{
|
2010-06-01 05:38:44 +08:00
|
|
|
struct thread *thread = perf_session__findnew(session, self->comm.tid);
|
2009-11-28 02:29:22 +08:00
|
|
|
|
2010-06-01 05:38:44 +08:00
|
|
|
dump_printf(": %s:%d\n", self->comm.comm, self->comm.tid);
|
2009-11-28 02:29:22 +08:00
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
if (thread == NULL || thread__set_comm_adjust(thread, self->comm.comm,
|
|
|
|
&session->hists)) {
|
2009-11-28 02:29:22 +08:00
|
|
|
dump_printf("problem processing PERF_RECORD_COMM, skipping event.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-15 01:06:01 +08:00
|
|
|
int event__process_lost(event_t *self, struct perf_session *session)
|
2009-11-28 02:29:22 +08:00
|
|
|
{
|
|
|
|
dump_printf(": id:%Ld: lost:%Ld\n", self->lost.id, self->lost.lost);
|
2010-05-15 00:16:55 +08:00
|
|
|
session->hists.stats.total_lost += self->lost.lost;
|
2009-11-28 02:29:22 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
static void event_set_kernel_mmap_len(struct map **maps, event_t *self)
|
|
|
|
{
|
|
|
|
maps[MAP__FUNCTION]->start = self->mmap.start;
|
|
|
|
maps[MAP__FUNCTION]->end = self->mmap.start + self->mmap.len;
|
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
maps[MAP__FUNCTION]->end = ~0UL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int event__process_kernel_mmap(event_t *self,
|
|
|
|
struct perf_session *session)
|
2009-11-28 02:29:22 +08:00
|
|
|
{
|
2010-01-06 02:50:31 +08:00
|
|
|
struct map *map;
|
2010-04-19 13:32:50 +08:00
|
|
|
char kmmap_prefix[PATH_MAX];
|
2010-04-28 08:17:50 +08:00
|
|
|
struct machine *machine;
|
2010-04-19 13:32:50 +08:00
|
|
|
enum dso_kernel_type kernel_type;
|
|
|
|
bool is_kernel_mmap;
|
|
|
|
|
2010-04-28 08:17:50 +08:00
|
|
|
machine = perf_session__findnew_machine(session, self->mmap.pid);
|
|
|
|
if (!machine) {
|
|
|
|
pr_err("Can't find id %d's machine\n", self->mmap.pid);
|
2010-04-19 13:32:50 +08:00
|
|
|
goto out_problem;
|
|
|
|
}
|
2009-11-28 02:29:22 +08:00
|
|
|
|
2010-04-28 08:19:05 +08:00
|
|
|
machine__mmap_name(machine, kmmap_prefix, sizeof(kmmap_prefix));
|
2010-04-28 08:17:50 +08:00
|
|
|
if (machine__is_host(machine))
|
2010-04-19 13:32:50 +08:00
|
|
|
kernel_type = DSO_TYPE_KERNEL;
|
|
|
|
else
|
|
|
|
kernel_type = DSO_TYPE_GUEST_KERNEL;
|
2009-11-28 02:29:22 +08:00
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
is_kernel_mmap = memcmp(self->mmap.filename,
|
|
|
|
kmmap_prefix,
|
|
|
|
strlen(kmmap_prefix)) == 0;
|
|
|
|
if (self->mmap.filename[0] == '/' ||
|
|
|
|
(!is_kernel_mmap && self->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 23:22:17 +08:00
|
|
|
|
2010-04-19 13:32:50 +08: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 23:22:17 +08:00
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
if (self->mmap.filename[0] == '/') {
|
|
|
|
name = strrchr(self->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 23:22:17 +08: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 13:32:50 +08: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 23:22:17 +08:00
|
|
|
strxfrchar(short_module_name, '-', '_');
|
2010-04-19 13:32:50 +08:00
|
|
|
} else
|
|
|
|
strcpy(short_module_name, self->mmap.filename);
|
|
|
|
|
2010-04-28 08:20:43 +08:00
|
|
|
map = machine__new_module(machine, self->mmap.start,
|
|
|
|
self->mmap.filename);
|
2010-04-19 13:32:50 +08: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 02:11:30 +08:00
|
|
|
map->dso->sname_alloc = 1;
|
2010-04-19 13:32:50 +08:00
|
|
|
map->end = map->start + self->mmap.len;
|
|
|
|
} else if (is_kernel_mmap) {
|
|
|
|
const char *symbol_name = (self->mmap.filename +
|
|
|
|
strlen(kmmap_prefix));
|
|
|
|
/*
|
|
|
|
* Should be there already, from the build-id table in
|
|
|
|
* the header.
|
|
|
|
*/
|
2010-04-28 08:17:50 +08:00
|
|
|
struct dso *kernel = __dsos__findnew(&machine->kernel_dsos,
|
|
|
|
kmmap_prefix);
|
2010-04-19 13:32:50 +08:00
|
|
|
if (kernel == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
kernel->kernel = kernel_type;
|
2010-04-28 08:20:43 +08:00
|
|
|
if (__machine__create_kernel_maps(machine, kernel) < 0)
|
2010-04-19 13:32:50 +08:00
|
|
|
goto out_problem;
|
|
|
|
|
2010-04-28 08:17:50 +08:00
|
|
|
event_set_kernel_mmap_len(machine->vmlinux_maps, self);
|
|
|
|
perf_session__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps,
|
|
|
|
symbol_name,
|
|
|
|
self->mmap.pgoff);
|
|
|
|
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 23:22:17 +08:00
|
|
|
/*
|
2010-04-19 13:32:50 +08: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 23:22:17 +08:00
|
|
|
*/
|
2010-04-28 08:17:50 +08:00
|
|
|
dso__load(kernel, machine->vmlinux_maps[MAP__FUNCTION],
|
|
|
|
NULL);
|
2010-04-19 13:32:50 +08: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 23:22:17 +08:00
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
int event__process_mmap(event_t *self, struct perf_session *session)
|
|
|
|
{
|
2010-04-28 08:17:50 +08:00
|
|
|
struct machine *machine;
|
2010-04-19 13:32:50 +08:00
|
|
|
struct thread *thread;
|
|
|
|
struct map *map;
|
|
|
|
u8 cpumode = self->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
|
|
|
|
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 23:22:17 +08:00
|
|
|
|
2010-04-19 13:32:50 +08:00
|
|
|
dump_printf(" %d/%d: [%#Lx(%#Lx) @ %#Lx]: %s\n",
|
|
|
|
self->mmap.pid, self->mmap.tid, self->mmap.start,
|
|
|
|
self->mmap.len, self->mmap.pgoff, self->mmap.filename);
|
|
|
|
|
|
|
|
if (cpumode == PERF_RECORD_MISC_GUEST_KERNEL ||
|
|
|
|
cpumode == PERF_RECORD_MISC_KERNEL) {
|
|
|
|
ret = event__process_kernel_mmap(self, session);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out_problem;
|
2010-01-06 02:50:31 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-04-28 08:17:50 +08:00
|
|
|
machine = perf_session__find_host_machine(session);
|
2010-05-10 08:14:07 +08:00
|
|
|
if (machine == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
thread = perf_session__findnew(session, self->mmap.pid);
|
2010-07-31 05:31:28 +08:00
|
|
|
if (thread == NULL)
|
|
|
|
goto out_problem;
|
2010-04-28 08:17:50 +08:00
|
|
|
map = map__new(&machine->user_dsos, self->mmap.start,
|
2010-04-19 13:32:50 +08:00
|
|
|
self->mmap.len, self->mmap.pgoff,
|
|
|
|
self->mmap.pid, self->mmap.filename,
|
2010-07-27 23:40:02 +08:00
|
|
|
MAP__FUNCTION);
|
2010-07-31 05:31:28 +08: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 23:22:17 +08:00
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
thread__insert_map(thread, map);
|
|
|
|
return 0;
|
2009-11-28 02:29:22 +08: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 23:22:17 +08:00
|
|
|
out_problem:
|
|
|
|
dump_printf("problem processing PERF_RECORD_MMAP, skipping event.\n");
|
2009-11-28 02:29:22 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-14 05:50:28 +08:00
|
|
|
int event__process_task(event_t *self, struct perf_session *session)
|
2009-11-28 02:29:22 +08:00
|
|
|
{
|
2010-06-01 06:43:07 +08:00
|
|
|
struct thread *thread = perf_session__findnew(session, self->fork.tid);
|
|
|
|
struct thread *parent = perf_session__findnew(session, self->fork.ptid);
|
2009-11-28 02:29:22 +08:00
|
|
|
|
|
|
|
dump_printf("(%d:%d):(%d:%d)\n", self->fork.pid, self->fork.tid,
|
|
|
|
self->fork.ppid, self->fork.ptid);
|
|
|
|
|
2010-06-17 19:37:44 +08:00
|
|
|
if (self->header.type == PERF_RECORD_EXIT) {
|
|
|
|
perf_session__remove_thread(session, thread);
|
2009-11-28 02:29:22 +08:00
|
|
|
return 0;
|
2010-06-17 19:37:44 +08:00
|
|
|
}
|
2009-11-28 02:29:22 +08: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 02:29:23 +08:00
|
|
|
|
2010-01-15 09:45:29 +08:00
|
|
|
void thread__find_addr_map(struct thread *self,
|
|
|
|
struct perf_session *session, u8 cpumode,
|
2010-04-19 13:32:50 +08:00
|
|
|
enum map_type type, pid_t pid, u64 addr,
|
2010-01-15 09:45:29 +08: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 02:29:23 +08:00
|
|
|
{
|
2009-12-12 00:50:36 +08:00
|
|
|
struct map_groups *mg = &self->mg;
|
2010-04-28 08:17:50 +08:00
|
|
|
struct machine *machine = 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 02:29:23 +08:00
|
|
|
|
2009-12-12 00:50:36 +08: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 02:29:23 +08:00
|
|
|
al->addr = addr;
|
2010-04-19 13:32:50 +08: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 02:29:23 +08:00
|
|
|
|
2010-04-19 13:32:50 +08: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 02:29:23 +08:00
|
|
|
al->level = 'k';
|
2010-04-28 08:17:50 +08:00
|
|
|
machine = perf_session__find_host_machine(session);
|
2010-05-10 08:14:07 +08:00
|
|
|
if (machine == NULL) {
|
|
|
|
al->map = NULL;
|
|
|
|
return;
|
|
|
|
}
|
2010-04-28 08:17:50 +08:00
|
|
|
mg = &machine->kmaps;
|
2010-04-19 13:32:50 +08: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 02:29:23 +08:00
|
|
|
al->level = '.';
|
2010-04-28 08:17:50 +08:00
|
|
|
machine = perf_session__find_host_machine(session);
|
2010-04-19 13:32:50 +08:00
|
|
|
} else if (cpumode == PERF_RECORD_MISC_GUEST_KERNEL && perf_guest) {
|
|
|
|
al->level = 'g';
|
2010-04-28 08:17:50 +08:00
|
|
|
machine = perf_session__find_machine(session, pid);
|
2010-05-10 08:14:07 +08:00
|
|
|
if (machine == NULL) {
|
2010-04-19 13:32:50 +08:00
|
|
|
al->map = NULL;
|
|
|
|
return;
|
|
|
|
}
|
2010-04-28 08:17:50 +08:00
|
|
|
mg = &machine->kmaps;
|
2010-04-19 13:32:50 +08: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 02:29:23 +08:00
|
|
|
al->map = NULL;
|
2010-04-19 13:32:50 +08: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 02:29:23 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
try_again:
|
2009-12-12 00:50:36 +08: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 02:29:23 +08: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 13:32:50 +08:00
|
|
|
if ((long long)al->addr < 0 &&
|
2010-04-28 08:17:50 +08:00
|
|
|
cpumode == PERF_RECORD_MISC_KERNEL &&
|
|
|
|
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 02:29:23 +08:00
|
|
|
goto try_again;
|
|
|
|
}
|
2010-01-15 09:45:29 +08: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 02:29:23 +08:00
|
|
|
al->addr = al->map->map_ip(al->map, al->addr);
|
2010-01-15 09:45:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void thread__find_addr_location(struct thread *self,
|
|
|
|
struct perf_session *session, u8 cpumode,
|
2010-04-19 13:32:50 +08:00
|
|
|
enum map_type type, pid_t pid, u64 addr,
|
2010-01-15 09:45:29 +08:00
|
|
|
struct addr_location *al,
|
|
|
|
symbol_filter_t filter)
|
|
|
|
{
|
2010-04-19 13:32:50 +08:00
|
|
|
thread__find_addr_map(self, session, cpumode, type, pid, addr, al);
|
2010-01-15 09:45:29 +08:00
|
|
|
if (al->map != NULL)
|
2010-02-04 02:52:00 +08:00
|
|
|
al->sym = map__find_symbol(al->map, al->addr, filter);
|
2010-01-15 09:45:29 +08: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 02:29:23 +08:00
|
|
|
}
|
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
static void dso__calc_col_width(struct dso *self, struct hists *hists)
|
2009-12-16 06:04:41 +08:00
|
|
|
{
|
|
|
|
if (!symbol_conf.col_width_list_str && !symbol_conf.field_sep &&
|
|
|
|
(!symbol_conf.dso_list ||
|
|
|
|
strlist__has_entry(symbol_conf.dso_list, self->name))) {
|
2010-07-21 01:42:52 +08:00
|
|
|
u16 slen = dso__name_len(self);
|
|
|
|
hists__new_col_len(hists, HISTC_DSO, slen);
|
2009-12-16 06:04:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
self->slen_calculated = 1;
|
|
|
|
}
|
|
|
|
|
2009-12-14 05:50:28 +08:00
|
|
|
int event__preprocess_sample(const event_t *self, struct perf_session *session,
|
2010-06-04 19:02:07 +08:00
|
|
|
struct addr_location *al, struct sample_data *data,
|
|
|
|
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 02:29:23 +08:00
|
|
|
{
|
|
|
|
u8 cpumode = self->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
|
2010-06-04 19:02:07 +08:00
|
|
|
struct thread *thread;
|
|
|
|
|
|
|
|
event__parse_sample(self, session->sample_type, data);
|
|
|
|
|
|
|
|
dump_printf("(IP, %d): %d/%d: %#Lx period: %Ld cpu:%d\n",
|
|
|
|
self->header.misc, data->pid, data->tid, data->ip,
|
|
|
|
data->period, data->cpu);
|
|
|
|
|
|
|
|
if (session->sample_type & PERF_SAMPLE_CALLCHAIN) {
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
dump_printf("... chain: nr:%Lu\n", data->callchain->nr);
|
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 02:29:23 +08:00
|
|
|
|
2010-06-04 19:02:07 +08:00
|
|
|
if (!ip_callchain__valid(data->callchain, self)) {
|
|
|
|
pr_debug("call-chain problem with event, "
|
|
|
|
"skipping it.\n");
|
|
|
|
goto out_filtered;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dump_trace) {
|
|
|
|
for (i = 0; i < data->callchain->nr; i++)
|
|
|
|
dump_printf("..... %2d: %016Lx\n",
|
|
|
|
i, data->callchain->ips[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
thread = perf_session__findnew(session, self->ip.pid);
|
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 02:29:23 +08:00
|
|
|
if (thread == NULL)
|
|
|
|
return -1;
|
|
|
|
|
2009-12-16 06:04:41 +08: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 02:29:23 +08:00
|
|
|
dump_printf(" ... thread: %s:%d\n", thread->comm, thread->pid);
|
2010-05-10 06:57:08 +08:00
|
|
|
/*
|
|
|
|
* Have we already created the kernel maps for the host machine?
|
|
|
|
*
|
|
|
|
* 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 &&
|
|
|
|
session->host_machine.vmlinux_maps[MAP__FUNCTION] == NULL)
|
|
|
|
machine__create_kernel_maps(&session->host_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 02:29:23 +08:00
|
|
|
|
2010-03-25 03:40:15 +08:00
|
|
|
thread__find_addr_map(thread, session, cpumode, MAP__FUNCTION,
|
2010-04-19 13:32:50 +08:00
|
|
|
self->ip.pid, self->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 02:29:23 +08:00
|
|
|
dump_printf(" ...... dso: %s\n",
|
|
|
|
al->map ? al->map->dso->long_name :
|
|
|
|
al->level == 'H' ? "[hypervisor]" : "<not found>");
|
2010-03-25 03:40:15 +08:00
|
|
|
al->sym = NULL;
|
2010-06-04 22:27:10 +08:00
|
|
|
al->cpu = data->cpu;
|
2010-03-25 03:40:15 +08: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;
|
|
|
|
/*
|
|
|
|
* We have to do this here as we may have a dso with no symbol
|
|
|
|
* hit that has a name longer than the ones with symbols
|
|
|
|
* sampled.
|
|
|
|
*/
|
|
|
|
if (!sort_dso.elide && !al->map->dso->slen_calculated)
|
2010-07-21 01:42:52 +08:00
|
|
|
dso__calc_col_width(al->map->dso, &session->hists);
|
2010-03-25 03:40:15 +08:00
|
|
|
|
|
|
|
al->sym = map__find_symbol(al->map, al->addr, filter);
|
2010-05-10 03:07:01 +08:00
|
|
|
} else {
|
|
|
|
const unsigned int unresolved_col_width = BITS_PER_LONG / 4;
|
|
|
|
|
2010-07-21 01:42:52 +08:00
|
|
|
if (hists__col_len(&session->hists, HISTC_DSO) < unresolved_col_width &&
|
2010-05-10 03:07:01 +08:00
|
|
|
!symbol_conf.col_width_list_str && !symbol_conf.field_sep &&
|
|
|
|
!symbol_conf.dso_list)
|
2010-07-21 01:42:52 +08:00
|
|
|
hists__set_col_len(&session->hists, HISTC_DSO,
|
|
|
|
unresolved_col_width);
|
2010-03-25 03:40:15 +08:00
|
|
|
}
|
2009-12-16 06:04:41 +08: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 02:29:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2009-12-06 19:08:24 +08:00
|
|
|
|
2010-06-04 19:02:07 +08:00
|
|
|
int event__parse_sample(const event_t *event, u64 type, struct sample_data *data)
|
2009-12-06 19:08:24 +08:00
|
|
|
{
|
2010-06-04 19:02:07 +08:00
|
|
|
const u64 *array = event->sample.array;
|
2009-12-06 19:08:24 +08:00
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_IP) {
|
|
|
|
data->ip = event->ip.ip;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_TID) {
|
|
|
|
u32 *p = (u32 *)array;
|
|
|
|
data->pid = p[0];
|
|
|
|
data->tid = p[1];
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_TIME) {
|
|
|
|
data->time = *array;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_ADDR) {
|
|
|
|
data->addr = *array;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
2010-05-04 19:19:15 +08:00
|
|
|
data->id = -1ULL;
|
2009-12-06 19:08:24 +08:00
|
|
|
if (type & PERF_SAMPLE_ID) {
|
|
|
|
data->id = *array;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_STREAM_ID) {
|
|
|
|
data->stream_id = *array;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_CPU) {
|
|
|
|
u32 *p = (u32 *)array;
|
|
|
|
data->cpu = *p;
|
|
|
|
array++;
|
2010-05-28 18:08:01 +08:00
|
|
|
} else
|
|
|
|
data->cpu = -1;
|
2009-12-06 19:08:24 +08:00
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_PERIOD) {
|
|
|
|
data->period = *array;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_READ) {
|
|
|
|
pr_debug("PERF_SAMPLE_READ is unsuported for now\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_CALLCHAIN) {
|
|
|
|
data->callchain = (struct ip_callchain *)array;
|
|
|
|
array += 1 + data->callchain->nr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type & PERF_SAMPLE_RAW) {
|
|
|
|
u32 *p = (u32 *)array;
|
|
|
|
data->raw_size = *p;
|
|
|
|
p++;
|
|
|
|
data->raw_data = p;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|