There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
this particular patch, it will apply cleanly and has been tested all
the way back to 2.6.36.
The kprobes code uses the text_poke() function which accommodates
writi
The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite. This is
because the test suite did not fully implement the behavior of a real
debugger. A real debugger tracks the state of what thread it asked to
single step and can cor
The Smatch tool warned that the change from commit b8adde8dd
(kdb: Avoid using dbg_io_ops until it is initialized) should
add another null check later in the kdb_printf().
It is worth noting that the second use of dbg_io_ops->is_console
is protected by the KDB_PAGER state variable which would only
The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite. This is
because the test suite did not fully implement the behavior of a real
debugger. A real debugger tracks the state of what thread it asked to
single step and can cor
On x86 the kgdb test suite will oops when the kernel is compiled with
CONFIG_DEBUG_RODATA and you run the tests after boot time. This is
regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use
HW breakpoints with CONFIG_DEBUG_RODATA).
The test suite can use hw breakpoints for all the
There is extra state information that needs to be exposed in the
kgdb_bpt structure for tracking how a breakpoint was installed. The
debug_core only uses the the probe_kernel_write() to install
breakpoints, but this is not enough for all the archs. Some arch such
as x86 need to use text_poke() in
This is a set of accumulated regression fixes which will go to to
-stable once reviewed and merged to the mainline.
The break down looks likes this for >= kernel x.x
3.4: Fix an an Smatch warning that appeared in the 3.4 merge window
3.0: Fix kgdb suite with SMP for all archs without HW sin
On Thu, Mar 29, 2012 at 03:19:56AM -0400, Andrei E. Warkentin wrote:
> Hi Don,
>
> Thank you for your feedback!
>
> 2012/3/27 Don Zickus :
> >
> > Hmm, if try_panic fails, then the cpu continues on executing code. This
> > might further corrupt an already broken system. So I don't think this
>
Hi Don,
Thank you for your feedback!
2012/3/27 Don Zickus :
>
> Hmm, if try_panic fails, then the cpu continues on executing code. This
> might further corrupt an already broken system. So I don't think this
> patch will work as is.
>
I see what you are saying. I could make the argument that t
