Messages in this thread | | | Date | Mon, 23 Nov 2009 21:25:28 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 4/4] perf tools: Add support for breakpoint events in perf tools |
| |
On Mon, Nov 23, 2009 at 11:06:01PM +0530, K.Prasad wrote: > On Mon, Nov 23, 2009 at 03:42:35PM +0100, Frederic Weisbecker wrote: > > Add the breakpoint events support with this new sysnopsis: > > > > mem:addr[:access] > > > > Where addr is a raw addr value in the kernel and access can be > > either [r][w][x] > > > > Example to profile tasklist_lock: > > > > $ grep tasklist_lock /proc/kallsyms > > ffffffff8189c000 D tasklist_lock > > > > $ perf record -e mem:0xffffffff8189c000:rw -a -f -c 1 > > $ perf report > > The problem in obtaining just the breakpoint address is that there can > be a variety of breakpoint lengths that can be associated with them - > assigning the smallest possible length (1-Byte) may cause loss of > exceptions and a higher length would lead to stray exceptions (such > dilemmas led to the support of symbol-only breakpoint in ksym_tracer and > perf-tools in my patchset...the default 1-Byte breakpoint length being a > temporary fix).
Right.
> With kernel symbols as input it would be possible to derive the bkpt > length based on the symbol-size, say using > kallsyms_lookup_size_offset() (although the corresponding length may not > be available on the host processor such requests can be failed or > over-ridden by the user using a smaller length), but for addresses I think > it is vital to know what breakpoint length is desired by the user.
Yeah. I guess we first need a way to manually add this length, may be:
mem:addr/len:access
And as you said, finding it automatically for symbols. But still, passing symbols to perf attr leads to confusion and complexity if we want to profile in userspace.
I think we should find this symbol length from userspace. I'm not sure how yet, probably using Dwarf. Arnaldo, do you have an idea about that?
> This comes at the cost of exposing the user to variations in > breakpoint implementation across architectures and demand processor-specific > knowledge, but specifying a kernel-space address would anyway require the > user to penetrate beyond the normal abstraction provided by the > interface/tool...so I presume it must be acceptable.
Yeah. We'll probably need to write a quick sum-up about such variations to facilitate perf uses.
> On a related note, the supported breakpoint length for PPC64 is a fixed > 8-Byte length (which means all extraneous exceptions must be filtered by > the breakpoint architecture) and Book-E Power processors matching > addresses against a bitmask; for S390 it can be practically anything > (bound by a set of start and end addresses)...and you see what a > quandary it leads to! > > Thanks, > K.Prasad
Yep :)
Thanks.
| |