perf backtraces off-by-1

* perf backtraces off-by-1
@ 2012-08-24 22:13 Arun Sharma
  2012-08-26 16:10 ` Peter Zijlstra
  0 siblings, 1 reply; 5+ messages in thread
From: Arun Sharma @ 2012-08-24 22:13 UTC (permalink / raw)
  To: LKML
  Cc: Jiri Olsa, Arnaldo Carvalho de Melo, Benjamin Redelings,
	Corey Ashford, Cyrill Gorcunov, Frank Ch. Eigler,
	Frederic Weisbecker, Ingo Molnar, Masami Hiramatsu,
	Paul Mackerras, Peter Zijlstra, Robert Richter, Stephane Eranian,
	Tom Zanussi, Ulrich Drepper

Some of our language runtimes like to map IP addresses in perf backtrace 
to specific byte codes. The way things stand now, the addresses on the 
backtrace are return addresses, rather than the caller. I think this 
issue may be present for other unusual call/return sequences where the 
user may be more interested in the calling instruction rather than the 
instruction control flow would return to.

A simple hack such as the one below makes our JIT guys happy. But the
code is not right if there was an asynchronous transfer of control (eg:
signal handler or interrupt).

libunwind contains similar code, but has the additional info in the 
unwind information to recognize async control transfer.

Wondering if this has been discussed before. One option is to support 
this for user mode only, with code to detect signal frames. Any other ideas?

        -Arun

--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -296,6 +296,7 @@ int machine__resolve_callchain(struct machine *self, 
struct perf_evsel *evsel,
	u8 cpumode = PERF_RECORD_MISC_USER;
	unsigned int i;
	int err;
+	int async;

	callchain_cursor_reset(&evsel->hists.callchain_cursor);

@@ -322,6 +323,11 @@ int machine__resolve_callchain(struct machine 
*self, struct perf_evsel *evsel,
			continue;
		}

+		/* XXX: check if this was an async control transfer */
+		async = 0;
+                if (!async) {
+			ip--;
+		}
		al.filtered = false;
		thread__find_addr_location(thread, self, cpumode,
					   MAP__FUNCTION, ip, &al, NULL);



^ permalink raw reply	[flat|nested] 5+ messages in thread