Hello, I''m trying to use gdb and gdbserver-xen to walk through the instructions executed when starting up a domU kernel. We are using the current xen-unstable (linux-2.6.12-xenU). I have followed the instructions in tools/debugger/gdb/ and I am able to successfully attach to a running domU kernel. I have compiled the domU kernel with debug options as described in tools/debugger/gdb/README. After attaching to the running domU kernel, I observe the following behavior: Issuing the gdb commands ''step'', ''stepi'', ''next'', and ''nexti'' when the domU kernel is initially paused all crash the domU kernel silently (i.e., the state of said domU goes to ''c'' if you issue an `xm list` in dom0). ''continue'' causes the domU kernel to boot up correctly. All the breakpoints I''ve tried setting so far (setting the breakpoints before issuing the ''continue'' in gdb) cause the domU kernel to panic when the function at which the breakpoint is set gets run. Functions I''ve tried setting breakpoints for include dup_task_struct, queue_work, scheduler_tick, and activate_task. Is it possible to step through the domU kernel code as it is booted in Xen? Thanks, -Jon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
domu_debug must be enabled in xen''s Rules.mk <http://Rules.mk>, otherwise the int3 gets passed onto the OS which will cause it to crash as it isn''t expecting to see a debug trap in ring 0 (unless of course you have a debugger compiled into the kernel itself). Just re-compile and then pass -p (pause) to xm create followed by an attach with gdbserver-xen. -Kip On 9/27/05, Jonathan M. McCune <jonmccune@cmu.edu> wrote:> > Hello, > > I''m trying to use gdb and gdbserver-xen to walk through the instructions > executed when starting up a domU kernel. We are using the current > xen-unstable (linux-2.6.12-xenU). I have followed the instructions in > tools/debugger/gdb/ and I am able to successfully attach to a running > domU kernel. I have compiled the domU kernel with debug options as > described in tools/debugger/gdb/README. After attaching to the running > domU kernel, I observe the following behavior: > > Issuing the gdb commands ''step'', ''stepi'', ''next'', and ''nexti'' when the > domU kernel is initially paused all crash the domU kernel silently > (i.e., the state of said domU goes to ''c'' if you issue an `xm list` in > dom0). ''continue'' causes the domU kernel to boot up correctly. > > All the breakpoints I''ve tried setting so far (setting the breakpoints > before issuing the ''continue'' in gdb) cause the domU kernel to panic > when the function at which the breakpoint is set gets run. Functions > I''ve tried setting breakpoints for include dup_task_struct, queue_work, > scheduler_tick, and activate_task. > > Is it possible to step through the domU kernel code as it is booted in > Xen? > > Thanks, > -Jon > > > > _______________________________________________ > 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
> domu_debug must be enabled in xen''s Rules.mk, otherwise the > int3 gets passed onto the OS which will cause it to crash as > it isn''t expecting to see a debug trap in ring 0 (unless of > course you have a debugger compiled into the kernel itself). > > Just re-compile and then pass -p (pause) to xm create > followed by an attach with gdbserver-xen.Why don''t we have a dom0 op that sets this for a specific domain, hence when a debugger attaches to a domain we can route the int3 appropriately? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jonathan M. McCune
2005-Sep-28 14:32 UTC
Re: [Xen-devel] gdbserver-xen / gdb crashing domU
Hi Kip, Thanks for your quick response. Unfortunately, in the experiment I described in my first post, I did have domu_debug=y in xen/Rules.mk. I rebuilt and reinstalled xen after a `make clean` in the xen subdir just to be sure it would have picked up the change. Any other ideas? Thanks, -Jon Kip Macy wrote:>domu_debug must be enabled in xen''s Rules.mk <http://Rules.mk>, otherwise >the int3 gets passed onto the OS which will cause it to crash as it isn''t >expecting to see a debug trap in ring 0 (unless of course you have a >debugger compiled into the kernel itself). > >Just re-compile and then pass -p (pause) to xm create followed by an attach >with gdbserver-xen. > >-Kip > >On 9/27/05, Jonathan M. McCune <jonmccune@cmu.edu> wrote: > > >>Hello, >> >>I''m trying to use gdb and gdbserver-xen to walk through the instructions >>executed when starting up a domU kernel. We are using the current >>xen-unstable (linux-2.6.12-xenU). I have followed the instructions in >>tools/debugger/gdb/ and I am able to successfully attach to a running >>domU kernel. I have compiled the domU kernel with debug options as >>described in tools/debugger/gdb/README. After attaching to the running >>domU kernel, I observe the following behavior: >> >>Issuing the gdb commands ''step'', ''stepi'', ''next'', and ''nexti'' when the >>domU kernel is initially paused all crash the domU kernel silently >>(i.e., the state of said domU goes to ''c'' if you issue an `xm list` in >>dom0). ''continue'' causes the domU kernel to boot up correctly. >> >>All the breakpoints I''ve tried setting so far (setting the breakpoints >>before issuing the ''continue'' in gdb) cause the domU kernel to panic >>when the function at which the breakpoint is set gets run. Functions >>I''ve tried setting breakpoints for include dup_task_struct, queue_work, >>scheduler_tick, and activate_task. >> >>Is it possible to step through the domU kernel code as it is booted in >>Xen? >> >>Thanks, >>-Jon >> >> >> >>_______________________________________________ >>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
I vaguely recall it depending on debug as silly as that sounds. I'll have to go back and take a look - xen clearly isn't pausing the domain when an int3 is hit. -Kip On 9/28/05, Jonathan M. McCune <jonmccune@cmu.edu> wrote:> > Hi Kip, > > Thanks for your quick response. Unfortunately, in the experiment I > described in my first post, I did have domu_debug=y in xen/Rules.mk. I > rebuilt and reinstalled xen after a `make clean` in the xen subdir just > to be sure it would have picked up the change. > > Any other ideas? > > Thanks, > -Jon > > Kip Macy wrote: > > >domu_debug must be enabled in xen's Rules.mk <http://Rules.mk> < > http://Rules.mk>, otherwise > >the int3 gets passed onto the OS which will cause it to crash as it isn't > >expecting to see a debug trap in ring 0 (unless of course you have a > >debugger compiled into the kernel itself). > > > >Just re-compile and then pass -p (pause) to xm create followed by an > attach > >with gdbserver-xen. > > > >-Kip > > > >On 9/27/05, Jonathan M. McCune <jonmccune@cmu.edu> wrote: > > > > > >>Hello, > >> > >>I'm trying to use gdb and gdbserver-xen to walk through the instructions > >>executed when starting up a domU kernel. We are using the current > >>xen-unstable (linux-2.6.12-xenU). I have followed the instructions in > >>tools/debugger/gdb/ and I am able to successfully attach to a running > >>domU kernel. I have compiled the domU kernel with debug options as > >>described in tools/debugger/gdb/README. After attaching to the running > >>domU kernel, I observe the following behavior: > >> > >>Issuing the gdb commands 'step', 'stepi', 'next', and 'nexti' when the > >>domU kernel is initially paused all crash the domU kernel silently > >>(i.e., the state of said domU goes to 'c' if you issue an `xm list` in > >>dom0). 'continue' causes the domU kernel to boot up correctly. > >> > >>All the breakpoints I've tried setting so far (setting the breakpoints > >>before issuing the 'continue' in gdb) cause the domU kernel to panic > >>when the function at which the breakpoint is set gets run. Functions > >>I've tried setting breakpoints for include dup_task_struct, queue_work, > >>scheduler_tick, and activate_task. > >> > >>Is it possible to step through the domU kernel code as it is booted in > >>Xen? > >> > >>Thanks, > >>-Jon > >> > >> > >> > >>_______________________________________________ > >>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
Yes. We agreed to do that several months ago. Effectively adding to domains the equivalent of a process' traced flag. I've been largely sidelined with other things. I'll go dig up the old e-mails. -Kip Why don't we have a dom0 op that sets this for a specific domain, hence> when a debugger attaches to a domain we can route the int3 > appropriately? > > Ian >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel