RE: gdbserver-xen / gdb crashing domU

RE: gdbserver-xen / gdb crashing domU

[Ian Pratt]

> 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

Re: gdbserver-xen / gdb crashing domU

[Kip Macy]

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

gdbserver-xen / gdb crashing domU

[Jonathan M. McCune]

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

Re: gdbserver-xen / gdb crashing domU

[Kip Macy]

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

Re: gdbserver-xen / gdb crashing domU

[Jonathan M. McCune]

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

Re: gdbserver-xen / gdb crashing domU

[Kip Macy]

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