[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] please help: remote gdb


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "King, Steven R" <steven.r.king@xxxxxxxxx>
  • Date: Fri, 16 Dec 2005 11:06:35 -0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 16 Dec 2005 19:08:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYCax+jbS9540LQTwmwATHWdKPBwwABu4/g
  • Thread-topic: [Xen-devel] please help: remote gdb

The INT3 is in the kernel.  The domU and remote gdb both agree on the
EIP too.  It appears that the INT3 is simply passed to the domU kernel
rather than the debugger.  In the response to the INT3, the domU kernel
terminates the whole process with a nice register and stack dump and I
end up back at the command prompt.



-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
Sent: Friday, December 16, 2005 10:10 AM
To: King, Steven R
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] please help: remote gdb


On 16 Dec 2005, at 18:01, King, Steven R wrote:

> Do the directions given in tools/debugger/gdb/README work now?
> Everything goes OK, except when my domU hits the breakpoint, the INT3 
> is caught by the local kernel which terminates my process.  I've tried

> domu_debug=y and all that.  I also tried Kip's ptrace_enable.patch, 
> but I don't know if there is something else I need to do to get that 
> working correctly.
>
> Any guidance much appreciated!!

The gdb server is intended for debugging the domU kernel. If you place
int3 in userspace code the trap will not be propagated to the gdb
server.

  -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.