[lkml]   [2012]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] kgdb,debug_core,kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints
    On 03/21/2012 09:53 PM, Masami Hiramatsu wrote:
    > (2012/03/22 2:55), Jason Wessel wrote:
    >> There has long been a limitation using software breakpoints with a
    >> kernel compiled with CONFIG_DEBUG_RODATA. The kprobe breakpoint code
    >> has its own text_poke() function which accommodates writing a
    >> breakpoint into a read-only page. The debug_core can make use of the
    >> text_poke() capabilities by using the kprobes API, specifically
    >> arch_arm_kprobe() and arch_disarm_kprobe(). For now it is safe to use
    >> a single statically allocated kprobe structure to call the kprobes API
    >> because the debug_core breakpoint API is only used when the kernel is
    >> in the debug state.
    > You might misunderstand it. arch_*_kprobe() are not open APIs.
    > Those are kprobes internal APIs (which means that those functions
    > should be used only by kprobes).

    I was looking for an interface that solved the problem, without having
    to use text_poke directly which is arch specific. Eventually I would
    like to use the kprobes high level API, but it cannot not be used
    without taking a mutex presently. This is a separate problem to deal
    with at a later time, because the generic use of kprobes would be
    aimed at having robust single stepping.

    >> The debug_core will first attempt to use the traditional
    >> probe_kernel_write(), and next try using a kprobe breakpoint. The
    >> kgdb test suite was updated to run all the software breakpoint tests
    >> when using a kernel with built with CONFIG_DEBUG_RODATA.
    >> Signed-off-by: Jason Wessel <>
    > Nak.
    > No, please don't use kprobes internal function this way, because
    > you can't ensure that the arch_arm_kprobe() has no side-effect.
    > Why don't you use text_poke()? I see that the text_poke()
    > is only for x86, but you already have arch/x86/kernel/kgdb.c for
    > making your own wrapper function.

    I will use the arch specific provision to override the
    kgdb_arch_set_breakpoint() and use the text_poke() directly.

    Eventually I would like to use the same software breakpoint
    reservation system as kprobes, and that would happen if kgdb ever
    starts using kprobes for single stepping. A few years back we solved
    the problem for hardware breakpoints reservations where the kernel
    debugger, perf, ptrace, and kprobes all play nice.


     \ /
      Last update: 2012-03-22 13:01    [W:0.022 / U:0.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site