[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kdb - can't set breakpoint by default on x86
    On Wed, Sep 21, 2011 at 12:43 AM, Tim Bird <> wrote:
    > On 09/19/2011 07:38 PM, Dongdong Deng wrote:
    >> On Tue, Sep 20, 2011 at 8:14 AM, Tim Bird <> wrote:
    >>> I recently tried using KDB on a 3.0.1 kernel, on an x86 target, using
    >>> a fairly-close-to-default kernel configuration.
    >>> I found that I could not set a breakpoint.
    >>> It sets inside KDB, but then fails to apply the breakpoint when
    >>> resuming to user space:
    >>> --------------------------------
    >>> /proc # echo g >sysrq-trigger
    >>> [2689816.806249] SysRq : DEBUG
    >>> Entering kdb (current=0xc7661d40, pid 511) on processor 0 due to Keyboard Entry
    >>> [0]kdb> bp sys_sync
    >>> Instruction(i) BP #0 at 0xc111ce70 (sys_sync)
    >>>    is enabled  addr at 00000000c111ce70, hardtype=0 installed=0
    >>> [0]kdb> g
    >>> _kdb_bp_install: failed to set breakpoint at 0xc111ce70
    >>> /proc # sync
    >>> /proc #
    >>> --------------------------------
    >>> I discovered that this was due to the text segment being marked
    >>> read-only, by mark_rodata_ro() in arch/x86/mm/init_32.c
    >>> This is controlled by CONFIG_DEBUG_RODATA.  With CONFIG_DEBUG_RODATA=y,
    >>> I get the following message on startup:
    >>> Write protecting the kernel read-only data: 6245
    >>> Also, breakpoints don't work.
    >>> Turning this off solves the problem, but seems counter-intuitive.
    >>> Should I:
    >>> 1) turn off CONFIG_DEBUG_RODATA automatically when CONFIG_KGDB_KDB is set?
    >>> or
    >>> 2) make CONFIG_DEBUG_RODATA depend on !KGDB_KDB?
    >>> or
    >>> 3) something else more subtle?
    >> The CONFIG_DEBUG_RODATA  is the nightmare for new user of kgdb/kdb,
    >> Most of kgdb/kdb user meet this problem when they first time using
    >> without reading manual.
    > Thanks very much for the response!
    > Ha ha. Oh the irony!  I just recently wrote up a detailed usage guide
    > for KDB (see, and even included information about
    > CONFIG_DEBUG_RODATA that I copied from another document.

    Ahah, Your kdb guide is very useful, thank for you create it to us. :-)

    > But I didn't remember this in my own x86 testing.  This variable isn't
    > used on ARM, where I've been doing most of my work.
    > It turns out I should read my own documentation!!  :-)
    >> but as the CONFIG_DEBUG_RODATA is an security feature, most of distro
    >> enable it.(ex: ubuntu)
    >> and the distro enable kgdb/kdb debugger too,
    >> if the KGDB/KDB mutual exclusion with CONFIG_DEBUG_RODATA,  the distro
    >> just pick one...
    > I see - that's a problem.  It's probably better to avoid messing
    > with the CONFIG dependencies then.
    >> BTW:  the kprobe have the same problem, it didn't handle with
    > In any event, CONFIG_DEBUG_RODATA is badly named, as it now covers both
    > data and text (and it's not really related to DEBUG either).
    > But, having said that, maybe just an addition to the debug message
    > when failing to set the breakpoint would be useful?
    > Something like:
    > _kdb_bp_install: failed to set breakpoint at 0xc111ce70
    > Maybe kernel or data segment is read-only?
    > Please check that kernel is configured with CONFIG_DEBUG_RODATA=n
    > I can whip up a patch for this, but does anyone have any better
    > ideas?

    I agree with you , it is a good solution to avoid the conflict of

    and could help user to detect the problem.

    For the realizing,
    Maybe we add a debugger MACRO to control this debug message is good.

    KGDB/KDB set_breakpoint_function()


    error message for warning CONFIG_DEBUG_RODATA options.


    I CC to Jason for getting his's suggestion about above method. :-)

    -- Dongdong
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-09-21 12:27    [W:0.030 / U:1.668 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site