WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: possible changes was Re: [PATCH] make domu_debug run-tim

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: possible changes was Re: [PATCH] make domu_debug run-time option + fix int3 handling for MP
From: Kip Macy <kmacy@xxxxxxxxxx>
Date: Mon, 16 May 2005 13:26:21 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 16 May 2005 20:25:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9074edb14d15f0d308fc32d2065f6240@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 
> Not if I understand the purpose of this patch. As I understand it, the 
> sole reason for making domu_debug configurable per-domain is to 
> distinguish the cause of an 'int3' when you take an int3 trap. If a 
> domain is a domu_debug domain then you assume that any int3 is for the 
> domu debugger; otherwise, none are.

Correct.

> Apart from not being a very nice extension of the domain-building 
> interface, 

I won't argue that enabling it belongs in the domain-building interface. So 
lets 
not get stuck on that aspect.


> I think the correct solution is to have a breakpoint-setting 
> API within Xen that is shared by all of the debugger stubs. 

This is a very kernel-stub centric point of view.

> This would 
> allow each debugger to set and clear breakpoints (i.e., add and remove 
> int3 instructions), and would automatically demux int3 traps to the 
> correct debugger(s), and/or propagate the trap up to the guest kernel 
> if appropriate.

No differentiation is made between setting / removing int3 and other
modifications to memory in ptrace, /proc or the GDB stub protocol. What you're
basically asking is to move debugger state into xen by having xen know about who
put what breakpoints where. This is a non-trivial imposition and incompatible 
with the tools with which I am acquainted.



                                -Kip

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