Re: [PATCH 4/4] perf tools: Add support for breakpoint events inperf tools

[K.Prasad]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/