[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.086 / U:37.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site