All of lore.kernel.org
 help / color / mirror / Atom feed
* gdbserver-xen / gdb crashing domU
@ 2005-09-27 22:49 Jonathan M. McCune
  2005-09-28  1:59 ` Kip Macy
  0 siblings, 1 reply; 6+ messages in thread
From: Jonathan M. McCune @ 2005-09-27 22:49 UTC (permalink / raw)
  To: xen-devel; +Cc: bparno, Arvind Seshadri


[-- Attachment #1.1: Type: text/plain, Size: 1173 bytes --]

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


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdbserver-xen / gdb crashing domU
  2005-09-27 22:49 Jonathan M. McCune
@ 2005-09-28  1:59 ` Kip Macy
  2005-09-28 14:32   ` Jonathan M. McCune
  0 siblings, 1 reply; 6+ messages in thread
From: Kip Macy @ 2005-09-28  1:59 UTC (permalink / raw)
  To: Jonathan M. McCune; +Cc: bparno, xen-devel, Arvind Seshadri


[-- Attachment #1.1: Type: text/plain, Size: 1833 bytes --]

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
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2359 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: gdbserver-xen / gdb crashing domU
@ 2005-09-28 10:37 ` Ian Pratt
  2005-09-28 18:50   ` Kip Macy
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Pratt @ 2005-09-28 10:37 UTC (permalink / raw)
  To: Kip Macy, Jonathan M. McCune; +Cc: bparno, xen-devel, Arvind Seshadri

> 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdbserver-xen / gdb crashing domU
  2005-09-28  1:59 ` Kip Macy
@ 2005-09-28 14:32   ` Jonathan M. McCune
  2005-09-28 18:48     ` Kip Macy
  0 siblings, 1 reply; 6+ messages in thread
From: Jonathan M. McCune @ 2005-09-28 14:32 UTC (permalink / raw)
  To: Kip Macy; +Cc: bparno, xen-devel, Arvind Seshadri


[-- Attachment #1.1: Type: text/plain, Size: 2150 bytes --]

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
>>
>>
>>
>>
>>    
>>
>
>  
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdbserver-xen / gdb crashing domU
  2005-09-28 14:32   ` Jonathan M. McCune
@ 2005-09-28 18:48     ` Kip Macy
  0 siblings, 0 replies; 6+ messages in thread
From: Kip Macy @ 2005-09-28 18:48 UTC (permalink / raw)
  To: Jonathan M. McCune; +Cc: bparno, xen-devel, Arvind Seshadri


[-- Attachment #1.1: Type: text/plain, Size: 2529 bytes --]

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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3443 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdbserver-xen / gdb crashing domU
  2005-09-28 10:37 ` gdbserver-xen / gdb crashing domU Ian Pratt
@ 2005-09-28 18:50   ` Kip Macy
  0 siblings, 0 replies; 6+ messages in thread
From: Kip Macy @ 2005-09-28 18:50 UTC (permalink / raw)
  To: Ian Pratt; +Cc: bparno, Arvind Seshadri, xen-devel, Jonathan M. McCune


[-- Attachment #1.1: Type: text/plain, Size: 367 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 613 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-09-28 18:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <AcXD0FxHkvtyx4KaRKO323jkm7Ws5wASBRVA>
2005-09-28 10:37 ` gdbserver-xen / gdb crashing domU Ian Pratt
2005-09-28 18:50   ` Kip Macy
2005-09-27 22:49 Jonathan M. McCune
2005-09-28  1:59 ` Kip Macy
2005-09-28 14:32   ` Jonathan M. McCune
2005-09-28 18:48     ` Kip Macy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.