linux-kernel - Re: [RFC 00/15] perf: Add backtrace post dwarf unwind

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, 30 Mar 2012 01:59:19 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Jiri Olsa <jolsa@...hat.com>, acme@...hat.com, mingo@...e.hu,
	paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
	gorcunov@...nvz.org, tzanussi@...il.com, mhiramat@...hat.com,
	rostedt@...dmis.org, robert.richter@....com, fche@...hat.com,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [RFC 00/15] perf: Add backtrace post dwarf unwind

On Thu, 2012-03-29 at 10:04 -0700, Stephane Eranian wrote:
> I think the mechanism should allow the user to select which registers
> (you have that) but also where they are captured. You have
> the user level state, but you also want the interrupted state or the
> precise state, i.e., extracting the register at retirement of an
> instruction
> that caused the sampling PMU event (PEBS on Intel). Personally, I
> am interested in the last two. I had a prototype patch for those.
> It is based on the same approach in terms of register naming. You
> need to be able to name individual registers. That's obviously arch
> specific and you have that. Now there needs to be a way to indicate
> where the registers must to be captured. Note that you may want
> to combine user + interrupt states. So I think we may need multiple
> register bitmasks. 

This all comes very close to something I suggested to Masami once where
you could specify data to grab on [ku]probe hits. 

That is, when creating a [ku]probe based tracepoint you can specify
several variable/argument names and the userspace perf-probe bits will
use the dwarf info to figure out how to obtain the value of said var/arg
at the probe point (if possible, if not bail).

The kernel would simply get something along the lines of %rax->foo->bar,
or (%esp+x)->blah along with a size of the data structure to be found
there and copy whatever it finds out to the raw field.

So what you're saying is you basically want this for any possible
sample, not just [ku]probes.



--
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/