Re: [Xen-devel] Debugging Xen

["George Dunlap " <dunlapg@xxxxxxxxx>]

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