From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kip Macy Subject: Re: softirq change was Re: domu_debug support removed on march 25th from traps.c in -unstable Date: Wed, 13 Apr 2005 11:05:43 -0700 Message-ID: References: <93009ddb97d608b4b377dd941bfdbe87@cl.cam.ac.uk> <98f0605c58c187fcf208ffabd00cce56@cl.cam.ac.uk> Reply-To: Kip Macy Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <98f0605c58c187fcf208ffabd00cce56@cl.cam.ac.uk> 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: Keir Fraser Cc: xen-devel List-Id: xen-devel@lists.xenproject.org > You mean that the TF bit is not cleared by the domu_debug code when it > should be? The correct place to fix this is in > include/asm-x86/debugger.h in debugger_trap_entry(). Yes. Continuing after single-stepping no longer works. > In general (not using domu_debug) it is not Xen's job to clear TF. We > clear it when we 'bounce' the exception into the guest OS, but the > saved application stack frame will include EFLAGS with the TF bit still > set. This matches real hardware. No it isn't Xen's job to clear it under normal circumstances as that would break PTRACE_SINGLESTEP in user-space. However, it was what the PDB code was doing and it seemed easy enough to clear it there to emulate PTRACE_SINGLESTEP for the kernel. I honestly don't care where it happens, it is easy enough to clear the TF from xc_ptrace.c. I just happened to be *extremely* tired last night and was dealing with other issues, so I was frustrated when that didn't work. I'll just incorporate my fix to xc_ptrace.c in with the FreeBSD fixes for -unstable. -Kip