lkml.org 
[lkml]   [2012]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] kgdb,debug_core,kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints
    (2012/03/22 20:57), Jason Wessel wrote:
    > 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.

    I see.

    >>> 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 <jason.wessel@windriver.com>
    >>
    >> 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.

    Thanks! that's what I meant. You can use __weak attribute.

    > 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.

    Yeah, as far as I can see, current kprobes design assumes that
    there is no other part uses sw breakpoint in kernel. But there
    is kgdb now.
    I think kprobes can share the sw breakpoint instrumentation and
    single stepping with kgdb.

    Thank you,



    --
    Masami HIRAMATSU
    Software Platform Research Dept. Linux Technology Center
    Hitachi, Ltd., Yokohama Research Laboratory
    E-mail: masami.hiramatsu.pt@hitachi.com


    \
     
     \ /
      Last update: 2012-03-23 15:11    [W:0.042 / U:31.728 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site