2009-10-26 17:23:18 -04:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include "event.h"
|
|
|
|
#include "debug.h"
|
2009-12-13 16:50:27 -05:00
|
|
|
#include "session.h"
|
2009-12-15 17:04:41 -05:00
|
|
|
#include "sort.h"
|
2009-10-26 17:23:18 -04:00
|
|
|
#include "string.h"
|
2009-12-15 17:04:41 -05:00
|
|
|
#include "strlist.h"
|
2009-11-27 13:29:22 -05:00
|
|
|
#include "thread.h"
|
2009-10-26 17:23:18 -04:00
|
|
|
|
|
|
|
static pid_t event__synthesize_comm(pid_t pid, int full,
|
2010-01-07 16:59:40 -05:00
|
|
|
event__handler_t process,
|
2009-12-13 16:50:24 -05:00
|
|
|
struct perf_session *session)
|
2009-10-26 17:23:18 -04: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-13 16:50:24 -05:00
|
|
|
process(&ev, session);
|
2009-10-26 17:23:18 -04: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-13 16:50:24 -05:00
|
|
|
process(&ev, session);
|
2009-10-26 17:23:18 -04: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-07 16:59:40 -05:00
|
|
|
event__handler_t process,
|
2009-12-13 16:50:24 -05:00
|
|
|
struct perf_session *session)
|
2009-10-26 17:23:18 -04: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-14 20:45:28 -05:00
|
|
|
.header = {
|
|
|
|
.type = PERF_RECORD_MMAP,
|
|
|
|
.misc = 0, /* Just like the kernel, see kernel/perf_event.c __perf_event_mmap */
|
|
|
|
},
|
2009-10-26 17:23:18 -04: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;
|
|
|
|
|
|
|
|
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-13 16:50:24 -05:00
|
|
|
process(&ev, session);
|
2009-10-26 17:23:18 -04: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 10:22:17 -05:00
|
|
|
int event__synthesize_modules(event__handler_t process,
|
|
|
|
struct perf_session *session)
|
|
|
|
{
|
|
|
|
struct rb_node *nd;
|
|
|
|
|
|
|
|
for (nd = rb_first(&session->kmaps.maps[MAP__FUNCTION]);
|
|
|
|
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-01-14 20:45:28 -05:00
|
|
|
ev.mmap.header.misc = 1; /* kernel uses 0 for user space maps, see kernel/perf_event.c __perf_event_mmap */
|
perf tools: Encode kernel module mappings in perf.data
We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)
Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).
One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-13 10:22:17 -05: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;
|
|
|
|
|
|
|
|
memcpy(ev.mmap.filename, pos->dso->long_name,
|
|
|
|
pos->dso->long_name_len + 1);
|
|
|
|
process(&ev, session);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-01-07 16:59:40 -05:00
|
|
|
int event__synthesize_thread(pid_t pid, event__handler_t process,
|
2009-12-13 16:50:24 -05:00
|
|
|
struct perf_session *session)
|
2009-10-26 17:23:18 -04:00
|
|
|
{
|
2009-12-13 16:50:24 -05:00
|
|
|
pid_t tgid = event__synthesize_comm(pid, 1, process, session);
|
2009-10-26 17:23:18 -04:00
|
|
|
if (tgid == -1)
|
|
|
|
return -1;
|
2009-12-13 16:50:24 -05:00
|
|
|
return event__synthesize_mmap_events(pid, tgid, process, session);
|
2009-10-26 17:23:18 -04:00
|
|
|
}
|
|
|
|
|
2010-01-07 16:59:40 -05:00
|
|
|
void event__synthesize_threads(event__handler_t process,
|
2009-12-13 16:50:24 -05:00
|
|
|
struct perf_session *session)
|
2009-10-26 17:23:18 -04: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-13 16:50:24 -05:00
|
|
|
event__synthesize_thread(pid, process, session);
|
2009-10-26 17:23:18 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
closedir(proc);
|
|
|
|
}
|
2009-11-27 13:29:22 -05:00
|
|
|
|
2010-01-05 13:50:31 -05: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-15 15:08:27 -05: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-05 13:50:31 -05:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
args->start = start;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2010-01-07 16:59:40 -05:00
|
|
|
int event__synthesize_kernel_mmap(event__handler_t process,
|
2010-01-05 13:50:31 -05:00
|
|
|
struct perf_session *session,
|
|
|
|
const char *symbol_name)
|
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
event_t ev = {
|
2010-01-14 20:45:28 -05:00
|
|
|
.header = {
|
|
|
|
.type = PERF_RECORD_MMAP,
|
|
|
|
.misc = 1, /* kernel uses 0 for user space maps, see kernel/perf_event.c __perf_event_mmap */
|
|
|
|
},
|
2010-01-05 13:50:31 -05: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-01-14 15:30:06 -05:00
|
|
|
if (kallsyms__parse("/proc/kallsyms", &args, find_symbol_cb) <= 0)
|
2010-01-05 13:50:31 -05:00
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
size = snprintf(ev.mmap.filename, sizeof(ev.mmap.filename),
|
|
|
|
"[kernel.kallsyms.%s]", symbol_name) + 1;
|
|
|
|
size = ALIGN(size, sizeof(u64));
|
|
|
|
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 10:22:17 -05:00
|
|
|
ev.mmap.pgoff = args.start;
|
|
|
|
ev.mmap.start = session->vmlinux_maps[MAP__FUNCTION]->start;
|
|
|
|
ev.mmap.len = session->vmlinux_maps[MAP__FUNCTION]->end - ev.mmap.start ;
|
2010-01-05 13:50:31 -05:00
|
|
|
|
|
|
|
return process(&ev, session);
|
|
|
|
}
|
|
|
|
|
2009-12-15 17:04:42 -05:00
|
|
|
static void thread__comm_adjust(struct thread *self)
|
|
|
|
{
|
|
|
|
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))) {
|
|
|
|
unsigned int slen = strlen(comm);
|
|
|
|
|
|
|
|
if (slen > comms__col_width) {
|
|
|
|
comms__col_width = slen;
|
|
|
|
threads__col_width = slen + 6;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int thread__set_comm_adjust(struct thread *self, const char *comm)
|
|
|
|
{
|
|
|
|
int ret = thread__set_comm(self, comm);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
thread__comm_adjust(self);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-13 16:50:28 -05:00
|
|
|
int event__process_comm(event_t *self, struct perf_session *session)
|
2009-11-27 13:29:22 -05:00
|
|
|
{
|
2009-12-13 16:50:28 -05:00
|
|
|
struct thread *thread = perf_session__findnew(session, self->comm.pid);
|
2009-11-27 13:29:22 -05:00
|
|
|
|
2009-12-01 01:04:49 -05:00
|
|
|
dump_printf(": %s:%d\n", self->comm.comm, self->comm.pid);
|
2009-11-27 13:29:22 -05:00
|
|
|
|
2009-12-15 17:04:42 -05:00
|
|
|
if (thread == NULL || thread__set_comm_adjust(thread, self->comm.comm)) {
|
2009-11-27 13:29:22 -05:00
|
|
|
dump_printf("problem processing PERF_RECORD_COMM, skipping event.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-14 12:06:01 -05:00
|
|
|
int event__process_lost(event_t *self, struct perf_session *session)
|
2009-11-27 13:29:22 -05:00
|
|
|
{
|
|
|
|
dump_printf(": id:%Ld: lost:%Ld\n", self->lost.id, self->lost.lost);
|
2009-12-14 12:06:01 -05:00
|
|
|
session->events_stats.lost += self->lost.lost;
|
2009-11-27 13:29:22 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-13 16:50:27 -05:00
|
|
|
int event__process_mmap(event_t *self, struct perf_session *session)
|
2009-11-27 13:29:22 -05:00
|
|
|
{
|
2010-01-05 13:50:31 -05:00
|
|
|
struct thread *thread;
|
|
|
|
struct map *map;
|
2009-11-27 13:29:22 -05:00
|
|
|
|
2010-01-14 09:23:09 -05: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);
|
2009-11-27 13:29:22 -05: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 10:22:17 -05:00
|
|
|
if (self->mmap.pid == 0) {
|
|
|
|
static const char kmmap_prefix[] = "[kernel.kallsyms.";
|
|
|
|
|
|
|
|
if (self->mmap.filename[0] == '/') {
|
|
|
|
char short_module_name[1024];
|
|
|
|
char *name = strrchr(self->mmap.filename, '/'), *dot;
|
|
|
|
|
|
|
|
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),
|
|
|
|
"[%.*s]", (int)(dot - name), name);
|
|
|
|
strxfrchar(short_module_name, '-', '_');
|
|
|
|
|
|
|
|
map = perf_session__new_module_map(session,
|
|
|
|
self->mmap.start,
|
2010-01-15 10:17:51 -05:00
|
|
|
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 10:22:17 -05:00
|
|
|
if (map == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
2010-01-15 10:17:51 -05:00
|
|
|
name = strdup(short_module_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 10:22:17 -05:00
|
|
|
if (name == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
2010-01-15 10:17:51 -05:00
|
|
|
map->dso->short_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 10:22:17 -05:00
|
|
|
map->end = map->start + self->mmap.len;
|
|
|
|
} else if (memcmp(self->mmap.filename, kmmap_prefix,
|
|
|
|
sizeof(kmmap_prefix) - 1) == 0) {
|
|
|
|
const char *symbol_name = (self->mmap.filename +
|
|
|
|
sizeof(kmmap_prefix) - 1);
|
|
|
|
/*
|
|
|
|
* Should be there already, from the build-id table in
|
|
|
|
* the header.
|
|
|
|
*/
|
|
|
|
struct dso *kernel = __dsos__findnew(&dsos__kernel,
|
|
|
|
"[kernel.kallsyms]");
|
|
|
|
if (kernel == NULL)
|
|
|
|
goto out_problem;
|
|
|
|
|
2010-01-19 07:36:13 -05:00
|
|
|
kernel->kernel = 1;
|
2010-02-03 13:52:00 -05:00
|
|
|
if (__perf_session__create_kernel_maps(session, kernel) < 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 10:22:17 -05:00
|
|
|
goto out_problem;
|
|
|
|
|
|
|
|
session->vmlinux_maps[MAP__FUNCTION]->start = self->mmap.start;
|
|
|
|
session->vmlinux_maps[MAP__FUNCTION]->end = self->mmap.start + self->mmap.len;
|
2010-02-20 16:53:13 -05:00
|
|
|
/*
|
|
|
|
* Be a bit paranoid here, some perf.data file came with
|
|
|
|
* a zero sized synthesized MMAP event for the kernel.
|
|
|
|
*/
|
|
|
|
if (session->vmlinux_maps[MAP__FUNCTION]->end == 0)
|
|
|
|
session->vmlinux_maps[MAP__FUNCTION]->end = ~0UL;
|
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 10:22:17 -05:00
|
|
|
|
|
|
|
perf_session__set_kallsyms_ref_reloc_sym(session, symbol_name,
|
|
|
|
self->mmap.pgoff);
|
|
|
|
}
|
2010-01-05 13:50:31 -05:00
|
|
|
return 0;
|
|
|
|
}
|
2009-11-27 13:29:22 -05:00
|
|
|
|
2010-01-05 13:50:31 -05:00
|
|
|
thread = perf_session__findnew(session, self->mmap.pid);
|
|
|
|
map = map__new(&self->mmap, MAP__FUNCTION,
|
|
|
|
session->cwd, session->cwdlen);
|
2009-11-27 13:29:22 -05:00
|
|
|
|
|
|
|
if (thread == NULL || 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 10:22:17 -05:00
|
|
|
goto out_problem;
|
2009-11-27 13:29:22 -05: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 10:22:17 -05:00
|
|
|
thread__insert_map(thread, map);
|
|
|
|
return 0;
|
2009-11-27 13:29:22 -05: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 10:22:17 -05:00
|
|
|
out_problem:
|
|
|
|
dump_printf("problem processing PERF_RECORD_MMAP, skipping event.\n");
|
2009-11-27 13:29:22 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-13 16:50:28 -05:00
|
|
|
int event__process_task(event_t *self, struct perf_session *session)
|
2009-11-27 13:29:22 -05:00
|
|
|
{
|
2009-12-13 16:50:28 -05:00
|
|
|
struct thread *thread = perf_session__findnew(session, self->fork.pid);
|
|
|
|
struct thread *parent = perf_session__findnew(session, self->fork.ppid);
|
2009-11-27 13:29:22 -05:00
|
|
|
|
|
|
|
dump_printf("(%d:%d):(%d:%d)\n", self->fork.pid, self->fork.tid,
|
|
|
|
self->fork.ppid, self->fork.ptid);
|
|
|
|
/*
|
|
|
|
* A thread clone will have the same PID for both parent and child.
|
|
|
|
*/
|
|
|
|
if (thread == parent)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (self->header.type == PERF_RECORD_EXIT)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
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-27 13:29:23 -05:00
|
|
|
|
2010-01-14 20:45:29 -05:00
|
|
|
void thread__find_addr_map(struct thread *self,
|
|
|
|
struct perf_session *session, u8 cpumode,
|
|
|
|
enum map_type type, u64 addr,
|
|
|
|
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-27 13:29:23 -05:00
|
|
|
{
|
2009-12-11 11:50:36 -05:00
|
|
|
struct map_groups *mg = &self->mg;
|
perf tools: Consolidate symbol resolving across all tools
Now we have a very high level routine for simple tools to
process IP sample events:
int event__preprocess_sample(const event_t *self,
struct addr_location *al,
symbol_filter_t filter)
It receives the event itself and will insert new threads in the
global threads list and resolve the map and symbol, filling all
this info into the new addr_location struct, so that tools like
annotate and report can further process the event by creating
hist_entries in their specific way (with or without callgraphs,
etc).
It in turn uses the new next layer function:
void thread__find_addr_location(struct thread *self, u8 cpumode,
enum map_type type, u64 addr,
struct addr_location *al,
symbol_filter_t filter)
This one will, given a thread (userspace or the kernel kthread
one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
too in the near future) at the given cpumode, taking vdsos into
account (userspace hit, but kernel symbol) and will fill all
these details in the addr_location given.
Tools that need a more compact API for plain function
resolution, like 'kmem', can use this other one:
struct symbol *thread__find_function(struct thread *self, u64 addr,
symbol_filter_t filter)
So, to resolve a kernel symbol, that is all the 'kmem' tool
needs, its just a matter of calling:
sym = thread__find_function(kthread, addr, NULL);
The 'filter' parameter is needed because we do lazy
parsing/loading of ELF symtabs or /proc/kallsyms.
With this we remove more code duplication all around, which is
always good, huh? :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-27 13:29:23 -05:00
|
|
|
|
2009-12-11 11:50:36 -05: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-27 13:29:23 -05:00
|
|
|
al->addr = addr;
|
|
|
|
|
2010-02-08 22:43:05 -05:00
|
|
|
if (cpumode == PERF_RECORD_MISC_KERNEL) {
|
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-27 13:29:23 -05:00
|
|
|
al->level = 'k';
|
perf session: Move kmaps to perf_session
There is still some more work to do to disentangle map creation
from DSO loading, but this happens only for the kernel, and for
the early adopters of perf diff, where this disentanglement
matters most, we'll be testing different kernels, so no problem
here.
Further clarification: right now we create the kernel maps for
the various modules and discontiguous kernel text maps when
loading the DSO, we should do it as a two step process, first
creating the maps, for multiple mappings with the same DSO
store, then doing the dso load just once, for the first hit on
one of the maps sharing this DSO backing store.
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: <1260741029-4430-6-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-13 16:50:29 -05:00
|
|
|
mg = &session->kmaps;
|
2010-02-08 22:43:05 -05:00
|
|
|
} else if (cpumode == PERF_RECORD_MISC_USER)
|
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-27 13:29:23 -05:00
|
|
|
al->level = '.';
|
|
|
|
else {
|
|
|
|
al->level = 'H';
|
|
|
|
al->map = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
try_again:
|
2009-12-11 11:50:36 -05: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-27 13:29:23 -05: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.
|
|
|
|
*/
|
perf session: Move kmaps to perf_session
There is still some more work to do to disentangle map creation
from DSO loading, but this happens only for the kernel, and for
the early adopters of perf diff, where this disentanglement
matters most, we'll be testing different kernels, so no problem
here.
Further clarification: right now we create the kernel maps for
the various modules and discontiguous kernel text maps when
loading the DSO, we should do it as a two step process, first
creating the maps, for multiple mappings with the same DSO
store, then doing the dso load just once, for the first hit on
one of the maps sharing this DSO backing store.
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: <1260741029-4430-6-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-13 16:50:29 -05:00
|
|
|
if ((long long)al->addr < 0 && mg != &session->kmaps) {
|
|
|
|
mg = &session->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-27 13:29:23 -05:00
|
|
|
goto try_again;
|
|
|
|
}
|
2010-01-14 20:45:29 -05: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-27 13:29:23 -05:00
|
|
|
al->addr = al->map->map_ip(al->map, al->addr);
|
2010-01-14 20:45:29 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
void thread__find_addr_location(struct thread *self,
|
|
|
|
struct perf_session *session, u8 cpumode,
|
|
|
|
enum map_type type, u64 addr,
|
|
|
|
struct addr_location *al,
|
|
|
|
symbol_filter_t filter)
|
|
|
|
{
|
|
|
|
thread__find_addr_map(self, session, cpumode, type, addr, al);
|
|
|
|
if (al->map != NULL)
|
2010-02-03 13:52:00 -05:00
|
|
|
al->sym = map__find_symbol(al->map, al->addr, filter);
|
2010-01-14 20:45:29 -05: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-27 13:29:23 -05:00
|
|
|
}
|
|
|
|
|
2009-12-15 17:04:41 -05:00
|
|
|
static void dso__calc_col_width(struct dso *self)
|
|
|
|
{
|
|
|
|
if (!symbol_conf.col_width_list_str && !symbol_conf.field_sep &&
|
|
|
|
(!symbol_conf.dso_list ||
|
|
|
|
strlist__has_entry(symbol_conf.dso_list, self->name))) {
|
|
|
|
unsigned int slen = strlen(self->name);
|
|
|
|
if (slen > dsos__col_width)
|
|
|
|
dsos__col_width = slen;
|
|
|
|
}
|
|
|
|
|
|
|
|
self->slen_calculated = 1;
|
|
|
|
}
|
|
|
|
|
2009-12-13 16:50:28 -05:00
|
|
|
int event__preprocess_sample(const event_t *self, struct perf_session *session,
|
|
|
|
struct addr_location *al, 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-27 13:29:23 -05:00
|
|
|
{
|
|
|
|
u8 cpumode = self->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
|
2009-12-13 16:50:28 -05:00
|
|
|
struct thread *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-27 13:29:23 -05:00
|
|
|
|
|
|
|
if (thread == NULL)
|
|
|
|
return -1;
|
|
|
|
|
2009-12-15 17:04:41 -05: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-27 13:29:23 -05:00
|
|
|
dump_printf(" ... thread: %s:%d\n", thread->comm, thread->pid);
|
|
|
|
|
perf session: Move kmaps to perf_session
There is still some more work to do to disentangle map creation
from DSO loading, but this happens only for the kernel, and for
the early adopters of perf diff, where this disentanglement
matters most, we'll be testing different kernels, so no problem
here.
Further clarification: right now we create the kernel maps for
the various modules and discontiguous kernel text maps when
loading the DSO, we should do it as a two step process, first
creating the maps, for multiple mappings with the same DSO
store, then doing the dso load just once, for the first hit on
one of the maps sharing this DSO backing store.
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: <1260741029-4430-6-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-13 16:50:29 -05:00
|
|
|
thread__find_addr_location(thread, session, cpumode, MAP__FUNCTION,
|
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-27 13:29:23 -05:00
|
|
|
self->ip.ip, al, filter);
|
|
|
|
dump_printf(" ...... dso: %s\n",
|
|
|
|
al->map ? al->map->dso->long_name :
|
|
|
|
al->level == 'H' ? "[hypervisor]" : "<not found>");
|
2009-12-15 17:04:41 -05:00
|
|
|
/*
|
|
|
|
* 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 (al->map && !sort_dso.elide && !al->map->dso->slen_calculated)
|
|
|
|
dso__calc_col_width(al->map->dso);
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
if (symbol_conf.sym_list && al->sym &&
|
|
|
|
!strlist__has_entry(symbol_conf.sym_list, al->sym->name))
|
|
|
|
goto out_filtered;
|
|
|
|
|
|
|
|
al->filtered = false;
|
|
|
|
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-27 13:29:23 -05:00
|
|
|
return 0;
|
|
|
|
}
|
2009-12-06 06:08:24 -05:00
|
|
|
|
|
|
|
int event__parse_sample(event_t *event, u64 type, struct sample_data *data)
|
|
|
|
{
|
|
|
|
u64 *array = event->sample.array;
|
|
|
|
|
|
|
|
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++;
|
|
|
|
}
|
|
|
|
|
|
|
|
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++;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|