linux-kernel - Re: [PATCH -tip v3 3/6] perf branch trace: print pid and command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Apr 2011 17:13:16 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	David Ahern <dsahern@...il.com>
Cc:	Akihiro Nagai <akihiro.nagai.hw@...achi.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	2nddept-manager@....hitachi.co.jp,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH -tip v3 3/6] perf branch trace: print pid and command

On Mon, Mar 28, 2011 at 08:31:23AM -0600, David Ahern wrote:
> On 03/28/11 04:34, Akihiro Nagai wrote:
> >> from is sample->ip? to is sample->addr? In the above example
> >> 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which
> >> resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.
> > Yes.
> > In this example, resolved address is only sample->ip (branch from).
> > We need the resolved address of sample->addr (branch to) too, because
> > both of them are addresses of execution code.
> 
> Ok, now I understand. In that case add conversion of sample->addr to
> symbols to perf-script.

I agree that we should rather use perf script for branch dumps.
Sorry Akihiro, I think we suggested you to create this dedicated
perf branch by the past. But then perf script became the vanilla dump
tool in the middle and it seems more suitable today.

We can still create a perf branch later in order to produce some more
advanced post-processing tools. But for sample dumps perf script (which starts
to show itself as a misnomer BTW) seems to be the right place.

So, in this context, if we have PERF_SAMPLE_ADDR, we are going to always
follow the ip with a "=>" and then resolve the address, etc...

Yeah it makes sense for this default mode. But what about when we'll want
a function graph kind of output? This will require a totally different
layout. Also PERF_SAMPLE_ADDR may be used for different context in the
future.

Perhaps we want a kind of per evsel callback that makes its own
interpretation of the pid/tid/dso/sym/etc... options asked by the
user?

But well, we can start simple and make and just do the => trick
if we have PERF_SAMPLE_ADDR and resolve addr if the user asked
the sym. Then when we have the graph output, have these per evsel
display callbacks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/