Re: kdb - can't set breakpoint by default on x86

[Dongdong Deng]

On Wed, Sep 21, 2011 at 12:43 AM, Tim Bird <tim.bird@xxxxxxxxxxx> wrote:
> On 09/19/2011 07:38 PM, Dongdong Deng wrote:
>> On Tue, Sep 20, 2011 at 8:14 AM, Tim Bird <tim.bird@xxxxxxxxxxx> 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.
>>> CONFIG_DEBUG_RODATA depends on CONFIG_DEBUG_KERNEL.
>>>
>>> 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 http://elinux.org/KDB), 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
>> CONFIG_DEBUG_RODATA too.
>
> 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
CONFIG_DEBUG_RODATA and CONFIG_KGDB

and could help user to detect the problem.

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

ex:
KGDB/KDB set_breakpoint_function()
{

set_bp_fail:

#ifdef CONFIG_DEBUG_RODATA
error message for warning CONFIG_DEBUG_RODATA options.
#endif

}

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/