Do people use kdb for live debugging of the linux kernel? I would
think that any interactive debugging (like single-stepping through a
function) would become bogged down in interrupt handlers, as there are
at least hundreds of timer interrupts, and probably interrupts from
other devices as well, coming in every second.
I think one of the standard things to do when you're doing some new,
complicated functionality is to use a ton of printks. It slows the
execution down by quite a bit, but lets you trace through exactly what
your code is doing. As you become confident that certain things are
behaving correctly, you can take out the printks.
When I'm tracking down a bug, I generally "single-step" through the
code visually (i.e., scan through the source code myself); if after
that, the path the hypervisor seems to be taking doesn't match the
pathI think it should, I add printks until I find where the difference
is.
Another option you could use is the xentrace functionality. Put trace
points at all of the key places in your code and analyze it later.
This may not work as well if you're tracking down a hypervisor crash,
however, as the latest trace records (presumably most pertinent to
analyzing the crash) may not have made it to disk yet.
The vast majority if my dev experience has been in kernel and
hypervisor, so I'm not familiar with using a debugger, but the idea of
just changing the result of an "if" statement as it's running seems a
little strange to me. :-) I think ideally you'd want to generate a
test input that would trigger the "other" if clause naturally.
If you really wanted to test the "other" path more often, you could
add a clause to the if statement to make it chose that option more
frequently -- for example, check to see that some bits of a counter
are all set to zero, or set up a Xen "magic" key command to set a
flag, so that the next time the if statement comes up the "other" path
is used. A keyhandler would be a little work to code up at first, but
you could easily re-use the code in the future if it turns out to be
useful.
-George
On 1/2/07, David Pilger <pilger.david@xxxxxxxxx> wrote:
On 1/2/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
>
> First, a happy new Year!
>
> What are the pros and cons of a xen-kernel debugger
> in your opinion?
>
Hi Christoph,
Happy new year!
In two words, code coverage.
Tracing over my code is my way to see if it is doing what it meant to
do. It's a programming practice I use, even if there aren't any bugs.
I'm aware that tracing is not possible at some portions of the
hypervisor, but calling a debugger loop that lets you perform actions
and interface through the serial driver is needed.
For instance, if you have a cretain IF condition in your code that
99.9% of the times it executes one path, how do you check the other
paths? mine is to change the IF condition on the fly with a debugger
and see how the program behaves on alternate paths. How do you
reproduce failures? my way is to think about all of the execution
paths that are possible for a certain situation and check all of them
using a debugger.
It all depends on the quality of the code that you produce, and the
lack of debugging capabilities at the hypervisor level makes it really
hard. Hypervisors today have a very critical role.
Anyway, this is just my need for such a debugger. but I guess others
will find it useful as well... For instance, to understand how open
source hypervisors such as Xen really works :)
How do you guys find it useful?
Thanks,
David.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home