From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Limpach Subject: Re: [PATCH] make domu_debug run-time option + fix int3handling for MP Date: Mon, 16 May 2005 23:31:17 +0100 Message-ID: <3d8eece2050516153144b7fa17@mail.gmail.com> References: Reply-To: Christian.Limpach@cl.cam.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com, Kip Macy List-Id: xen-devel@lists.xenproject.org On 5/16/05, Ian Pratt wrote: > > On Mon, May 16, 2005 at 03:08:24PM -0700, Kip Macy wrote: > > > "domu_debug" was mutually exclusive with crash_debug, which doesn't > > > make sense to me. The other stub already had a #if 0 as a > > > pre-processor guard around it. So the end effect with the patch is > > > that domu_debug would be on by default and cdb could be enabled at > > > compile-time. As I recall, there is no working > > functionality that this changes. I'll go back and look and > > recant if I am in error. > > > > Unless I misread the patch (didn't apply it), you'd end up > > with unconditional definitions of debugger_trap_fatal and > > debugger_trap_immediate? > > I usually just toggle the #elif 0 to enable the kdb stubs, I > > don't see how that would work now, without having to do more changes? >=20 > Do we ever want to enter cdb or kdb for any domain other than dom0? I > can't think why you'd want to, as there's a much nicer debug environment > available for domU's. debugger_trap_fatal and debugger_trap_immediate are only used in code paths which cause a Xen reboot and the nicer debug environment will be dead by then... Good point though for making debugger_trap_entry domu_debug only, might even be reasonable to rename it... christian