Messages in this thread | | | Date | Mon, 23 Nov 2009 23:06:01 +0530 | From | "K.Prasad" <> | Subject | Re: [PATCH 4/4] perf tools: Add support for breakpoint events in perf tools |
| |
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).
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.
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.
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
| |