[lkml]   [2010]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/6] hw-breakpoints updates

    Paul, there are some sh changes in this set. I couldn't test them
    by myself, do you think you could give it a try?

    You can pull the set from this branch:


    This new shot brings the following features:

    - You can now profile userspace memory accesses from perf, whenever
    you are profiling cpu wide or task wide

    - You can profile kernel memory accesses from perf if you are
    doing a task bound profiling (previously you could do it only for
    cpu wide profiling). That requires admin privileges though.
    So if you want to profile the global variable "A" in your "test"
    application. Get the address of "A" and do:

    perf record -e mem:addr_of_A:rw ./test

    - Separate constraint space between data and instruction breakpoints.
    If you have separate addr registers for your instruction and data
    breakpoints, one type won't eat the remaining slot constraints of
    the other in the constraint table.

    - Handle the weight of a breakpoint. Simple breakpoints only consume
    one register but range breakpoints or other complicated things
    may eat more. Handle this case in the constraint table.

    - Handle the fact we don't always know at build time the total number
    of available breakpoint registers. For example Arm needs to get this
    information dynamically on runtime.


    - ptrace usually get breakpoint informations through virtual arch
    regs provided by the user. This requires a wasteful level of indirection
    where we need to translate the arch info to generic info, and to translate
    back again to arch info. I need to implement a shortcut for the ptrace
    case. Not only is it wasteful, but we may lose some information in the
    process as the generic interface will never be able to integrate 100%
    of the subtleties that archs can implement for their breakpoints which
    can be expressed through arch register images in ptrace.
    We only want the most common features in the generic interface.

    - breakpoints are interesting with perf but only for addresses we
    know in advance (global variables). We need a trick to get dynamically
    allocated memory addresses. May be we could think about a generic
    solution with kprobes (which could then be usable later with uprobes) so
    that could get every instances of a given structure as they are allocated
    (or get these addresses later from a given point, still with kprobes).
    Once we get that, we could have a watchpoint based profiling tool that
    really rocks.

    Frederic Weisbecker (6):
    hw-breakpoints: Tag ptrace breakpoint as exclude_kernel
    hw-breakpoints: Check disabled breakpoints again
    hw-breakpoints: Change/Enforce some breakpoints policies
    hw-breakpoints: Separate constraint space for data and instruction
    hw-breakpoints: Handle breakpoint weight in allocation constraints
    hw-breakpoints: Get the number of available registers on boot

    arch/Kconfig | 11 ++
    arch/sh/Kconfig | 1 +
    arch/sh/include/asm/hw_breakpoint.h | 8 ++-
    arch/sh/kernel/hw_breakpoint.c | 31 +-----
    arch/sh/kernel/ptrace_32.c | 2 +-
    arch/x86/Kconfig | 1 +
    arch/x86/include/asm/hw_breakpoint.h | 10 ++-
    arch/x86/kernel/hw_breakpoint.c | 41 +------
    arch/x86/kernel/ptrace.c | 2 +-
    include/linux/hw_breakpoint.h | 25 ++++-
    kernel/hw_breakpoint.c | 196 +++++++++++++++++++++++++--------
    kernel/trace/trace_functions_graph.c | 2 +
    kernel/trace/trace_ksym.c | 26 ++----
    13 files changed, 220 insertions(+), 136 deletions(-)

     \ /
      Last update: 2010-04-23 07:17    [W:0.022 / U:11.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site