I'm debugging my kernel module, which appears to have a memory corruption, basically a piece of memory allocated by alloc_netdev() for 'net_device' instance has benn corrupted. I'm wondering if I could apply some "read-only" attribute on this memory, this way I expect to have Oops generated when someone tries to modify the memory.
Does it sound reasonable or my ideas are undoable ?
Thanks.
>I'm debugging my kernel module, which appears to have a memory corruption, >basically a piece of memory allocated by alloc_netdev() for 'net_device' >instance has benn corrupted. I'm wondering if I could apply some "read-only" >attribute on this memory, this way I expect to have Oops generated when >someone tries to modify the memory.
>Does it sound reasonable or my ideas are undoable ?
>Thanks.
>Mark
Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
corrupted. The processor will automatically stop and drop into kdb
when the location is modified.
See the documentation for the bp command in kdb under the Documentation
directory in the kernel source tree.
>>I'm debugging my kernel module, which appears to have a memory corruption,
>>basically a piece of memory allocated by alloc_netdev() for 'net_device'
>>instance has benn corrupted. I'm wondering if I could apply some >>"read-only"
>>attribute on this memory, this way I expect to have Oops generated when
>>someone tries to modify the memory.
>>Does it sound reasonable or my ideas are undoable ?
>>Thanks.
>>Mark
> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
> corrupted. The processor will automatically stop and drop into kdb
> when the location is modified.
> See the documentation for the bp command in kdb under the Documentation
> directory in the kernel source tree.
Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has only KGDB support, i.e. as I understand it allows to debug via rs232. What is the difference with KDB?
Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?
>"Scott Lurndal" <sc...@slp53.sl.home> wrote in message >news:JRTfs.4$Ci6.1@fe03.iad...
>>>I'm debugging my kernel module, which appears to have a memory corruption,
>>>basically a piece of memory allocated by alloc_netdev() for 'net_device'
>>>instance has benn corrupted. I'm wondering if I could apply some >>>"read-only"
>>>attribute on this memory, this way I expect to have Oops generated when
>>>someone tries to modify the memory.
>>>Does it sound reasonable or my ideas are undoable ?
>>>Thanks.
>>>Mark
>> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
>> corrupted. The processor will automatically stop and drop into kdb
>> when the location is modified.
>> See the documentation for the bp command in kdb under the Documentation
>> directory in the kernel source tree.
>Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has >only KGDB support, i.e. as I understand it allows to debug via rs232. What >is the difference with KDB?
KDB is built in; it doesn't require a client on another machine like KGDB;
but kgdb should work for your case since you've an earlier kernel.
KGDB and KDB both part of the kernel 3.x series, even for ARM as I understand it,
although I've seen recent changes fly by on LKML.
ARM processors also have external debug capabilities in some implementations
(e.g. ETM via jtag).
>Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and >CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?
The Kconfig files should handle any required dependencies for you.
> Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and > CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?
'magic sysreq' is mainly useful when you have some kind of
'interactive console connection' to a computer/ device and it is
necessary to send some kind of 'emergency command' to it after other
ways to interact with the system have ceased to function, eg, try
to write all dirty pages to disk, mount filesystems read-only and do a
'hard' reboot (without a proper shutdown procedure). For embedded,
that's likely not very useful. CONFIG_FRAME_POINTER is very likely a
good idea since this means that the subroutine activation records on
the call stack can be inspected without interpreting the actually
executed machine code.
>>> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
>>> corrupted. The processor will automatically stop and drop into kdb
>>> when the location is modified.
[skip]
>>Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has
>>only KGDB support, i.e. as I understand it allows to debug via rs232. What
>>is the difference with KDB?
> KDB is built in; it doesn't require a client on another machine like KGDB;
> but kgdb should work for your case since you've an earlier kernel.
After googling and reading I've set up kgdb over serial line, I can break into the debugger (by stopping the kernel via /proc/sysrq-trigger) and connect from host gdb, which is part of ARM toolchain.
Basically I have development board running embedded linux abd the driver I'm debugging, and my PC with two connections to the board - serial and ethernet (telnet session).
After I connect with host gdb to the target, I'm no longer able to do telnet to the board, because the only way to reproduce the memory corruption is to apply some configuration with user application on the board.
Is it expected or I'm doing something wrong, and there's a way to have alive IP connection to the target *and* GDB session?
> Basically I have development board running embedded linux abd the driver I'm
> debugging, and my PC with two connections to the board - serial and ethernet
> (telnet session).
Can't you test the driver in a more developer friendly environment (a simulation on your desktop) before deploying it on your target?
>"Scott Lurndal" <sc...@slp53.sl.home> wrote in message >news:R2Wfs.9$726.7@fed11.iad...
>>>> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
>>>> corrupted. The processor will automatically stop and drop into kdb
>>>> when the location is modified.
>[skip]
>>>Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has
>>>only KGDB support, i.e. as I understand it allows to debug via rs232. What
>>>is the difference with KDB?
>> KDB is built in; it doesn't require a client on another machine like KGDB;
>> but kgdb should work for your case since you've an earlier kernel.
>After googling and reading I've set up kgdb over serial line, I can break >into the debugger (by stopping the kernel via /proc/sysrq-trigger) and >connect from host gdb, which is part of ARM toolchain.
>Basically I have development board running embedded linux abd the driver I'm >debugging, and my PC with two connections to the board - serial and ethernet >(telnet session).
>After I connect with host gdb to the target, I'm no longer able to do telnet >to the board, because the only way to reproduce the memory corruption is to >apply some configuration with user application on the board.
>Is it expected or I'm doing something wrong, and there's a way to have alive >IP connection to the target *and* GDB session?
That's where you need kdb, instead of kgdb. With kdb, the serial port is
shared between the debugger and the host OS. The 3.5+ kernels have it built-in,
if I recall correctly.
I've never used kdgb, so I don't know if there is a way to multiplex the console
over the serial port along with the GDB protocol.
