All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: David Ahern <daahern@cisco.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	acme@ghostprotocols.net, mingo@elte.hu, peterz@infradead.org,
	paulus@samba.org, tglx@linutronix.de
Subject: Re: [PATCH 3/3] perf script: dump software events and samples from hardware-based profiling
Date: Thu, 3 Mar 2011 04:05:19 +0100	[thread overview]
Message-ID: <20110303030515.GD1946@nowhere> (raw)
In-Reply-To: <1299086960-26964-4-git-send-email-daahern@cisco.com>

On Wed, Mar 02, 2011 at 10:29:20AM -0700, David Ahern wrote:
> @@ -763,6 +783,18 @@ int cmd_script(int argc, const char **argv, const char *prefix __used)
>  		exit(-1);
>  	}
>  
> +	if (no_callchain)
> +		symbol_conf.use_callchain = false;
> +
> +	else {
> +		symbol_conf.use_callchain = true;
> +		if (callchain_register_param(&callchain_param) < 0) {

That call doesn't seem needed. Register callchain params is only useful
for later callchain sorting.

> +			error("Can't register callchain params\n");
> +			err = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
>  	if (rec_script_path)
>  		script_path = rec_script_path;
>  	if (rep_script_path)
[...]
> +void perf_session__print_sample(union perf_event *event,
> +				struct perf_sample *sample,
> +				struct perf_session *session,
> +				struct perf_event_attr *attr,
> +				bool show_unresolved)
> +{
> +	struct callchain_cursor_node *node, *prev;
> +	struct addr_location al;
> +	const char *evname = NULL;
> +	const char *comm;
> +	const char *symname, *dsoname;
> +	u32 cpu = -1;
> +	u64 secs = 0, usecs = 0;
> +
> +	if (perf_event__preprocess_sample(event, session, &al, sample,
> +					  NULL) < 0) {
> +		error("problem processing %d event, skipping it.\n",
> +			event->header.type);
> +		return;
> +	}
> +
> +	if (session->sample_type & PERF_SAMPLE_TIME) {
> +		u64 nsecs = sample->time;
> +		secs = nsecs / NSECS_PER_SEC;
> +		nsecs -= secs * NSECS_PER_SEC;
> +		usecs = nsecs / NSECS_PER_USEC;
> +	}
> +
> +   	evname = __event_name(attr->type, attr->config);
> +	if  (!evname)
> +		evname = "(unknown)";
> +
> +	comm = al.thread->comm_set ? al.thread->comm : "-";
> +
> +	if (attr->sample_type & PERF_SAMPLE_CPU)
> +		cpu = sample->cpu;
> +
> +	if (symbol_conf.use_callchain && sample->callchain) {
> +
> +		if (perf_session__resolve_callchain(session, al.thread,
> +						sample->callchain, NULL) != 0) {
> +			if (verbose)
> +				error("Failed to resolve callchain. Skipping\n");
> +			return;
> +		}
> +
> +		node = session->callchain_cursor.first;
> +		if (!node)
> +			return;
> +
> +		while (node) {
> +			if (node->sym && node->sym->name)
> +				symname = node->sym->name;
> +			else if (show_unresolved)
> +				symname = "";
> +			else
> +				goto next;
> +
> +			if (node->map && node->map->dso && node->map->dso->name)
> +				dsoname = node->map->dso->name;
> +			else if (show_unresolved)
> +				dsoname = "";
> +			else
> +				goto next;
> +
> +			print_one_symbol(comm, al.thread->pid, cpu, secs, usecs,
> +			             evname, node->ip, symname, dsoname);
> +
> +next:
> +			prev = node;
> +			node = node->next;

Hmm, that's a wrong way of walking through callchains. In fact it's not
a classical list. node->next can be a ghost entry from a previous callchain
that we kept cached in order to optimize allocations.

You need the accessors callchain_cursor_current() and callchain_cursor_advance().

  reply	other threads:[~2011-03-03  3:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02 17:29 [PATCH 0/3] perf script: add support for S/W events and H/W based profiling David Ahern
2011-03-02 17:29 ` [PATCH 1/3] perf script: change process_event prototype David Ahern
2011-03-03  2:40   ` Frederic Weisbecker
2011-03-03 14:11     ` David Ahern
2011-03-03 17:07       ` Frederic Weisbecker
2011-03-02 17:29 ` [PATCH 2/3] perf script: prepare to handle more than tracepoint events David Ahern
2011-03-02 17:29 ` [PATCH 3/3] perf script: dump software events and samples from hardware-based profiling David Ahern
2011-03-03  3:05   ` Frederic Weisbecker [this message]
2011-03-03 14:20     ` David Ahern
2011-03-03 17:19       ` Frederic Weisbecker
2011-03-03 17:30         ` David Ahern
2011-03-03 18:06           ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110303030515.GD1946@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@ghostprotocols.net \
    --cc=daahern@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.