Hi, How do you debug xen itself? For instance, if you want to debug a certain VMEXIT. Thanks, David, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31/12/06 4:19 pm, "David Pilger" <pilger.david@gmail.com> wrote:> How do you debug xen itself? > For instance, if you want to debug a certain VMEXIT.It depends exactly what kind of debugging you want to do. If it''s a Xen crash you might use the gdb serial stub built into Xen, or just add some printk tracing and reproduce the bug to get more info. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/31/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > It depends exactly what kind of debugging you want to do. If it''s a Xen > crash you might use the gdb serial stub built into Xen, or just add some > printk tracing and reproduce the bug to get more info. >Isn''t there a need to provide a BP mechanism that can help you PEEK into memory, instructions, etc...? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
First, a happy new Year! What are the pros and cons of a xen-kernel debugger in your opinion? On Monday 01 January 2007 10:07, David Pilger wrote:> On 12/31/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote: > > It depends exactly what kind of debugging you want to do. If it''s a Xen > > crash you might use the gdb serial stub built into Xen, or just add some > > printk tracing and reproduce the bug to get more info. > > Isn''t there a need to provide a BP mechanism that can help you PEEK > into memory, instructions, etc...?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/2/07, Christoph Egger <Christoph.Egger@amd.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@gmail.com> wrote:> On 1/2/07, Christoph Egger <Christoph.Egger@amd.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/2/07, George Dunlap <dunlapg@umich.edu> wrote:> 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. >Hi George, In certain application this is right, we both agree that code coverage is important in order to find bugs. The difference is that with a debugger you check alternate code flow in run-time, and without it you have to compile different version for each check. Run time flow alternations could be made in other ways than a debugger, but a debugger is more flexible and a lot of logic can be built at the client side, this lets you automate QA processes, etc... And ofcouse, a debugger has a zillion other uses as well :-) Thanks, David. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel