From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9959 invoked by alias); 11 Jan 2006 05:27:39 -0000 Received: (qmail 9951 invoked by uid 22791); 11 Jan 2006 05:27:38 -0000 X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jan 2006 05:27:35 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0B5RV7s003807; Wed, 11 Jan 2006 00:27:31 -0500 (EST) Received: from contents-vnder-pressvre.mit.edu (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.7.16.67]) (authenticated bits=56) (User authenticated as nathanw@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0B5RTFJ029010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jan 2006 00:27:30 -0500 (EST) Received: (from nathanw@localhost) by contents-vnder-pressvre.mit.edu (8.12.9) id k0B5RTYo015024; Wed, 11 Jan 2006 00:27:29 -0500 (EST) To: vexspam-gdbmail@usa.net Cc: Subject: Re: gdbserver-6.3 : Next command gets stuck then zooms. References: <192kaJwZr7568S07.1136931943@cmsweb07.cms.usa.net> From: "Nathan J. Williams" Date: Wed, 11 Jan 2006 05:27:00 -0000 In-Reply-To: <192kaJwZr7568S07.1136931943@cmsweb07.cms.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00089.txt.bz2 vexspam-gdbmail@usa.net writes: > In the Virtex-4 (405-ish as you know) the MSR doesn't have a single step > enable (SE bit) - it does have a debug interrupt enable (DE bit). > > If you know - what is the expected flow of operations I should be seeing > for the next command? Roughly, what the kernel should do is to set the DE bit in the MSR and also set the Instruction Complete (ICMP) bit in DBCR0, which gives you a trap after each instruction. However, you have to be sure your trap handler for the debug exception can handle (ignore and return from, mostly) debug traps that happen at the first instruction of *other* exception handlers, because the DE bit of the MSR isn't cleared when, for example, you take a TLB miss exception. So gdbserver calls ptrace(PTRACE_SSTEP), the kernel turns on ICMP and sets DE in the process's MSR, returns to userland, takes a TLB miss on the instruction for whatever reason, enters the TLB miss handler, and then takes a debug exception for the completion of the first instruction in the TLB miss handler. The debug exception handler needs to notice this (perhaps by checking the value of CSRR0 against known kernel code addresses or known exception handler code addresses), clear DE in CSRR1 but leave it alone in SRR1, and return to the TLB miss handler. The miss handler will then finish unmolested and return to the program, which can *then* trigger the debug exception for completing an instruction you were actually interested in. Have fun! - Nathan