From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31777 invoked by alias); 18 Oct 2006 14:04:06 -0000 Received: (qmail 31752 invoked by uid 22791); 18 Oct 2006 14:04:03 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 18 Oct 2006 14:03:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GaC1R-0001vg-ED for gdb@sourceware.org; Wed, 18 Oct 2006 10:03:53 -0400 Date: Wed, 18 Oct 2006 14:04:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Breakpoints in delay slots Message-ID: <20061018140353.GB7083@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <453608FC.2040201@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453608FC.2040201@st.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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-10/txt/msg00135.txt.bz2 On Wed, Oct 18, 2006 at 11:59:08AM +0100, Andrew STUBBS wrote: > Hi all, > > There is an occasional issue debugging programs on processors that use > delay slots - in my case the SH4. > > The problem occurs when a breakpoint is placed on the delay slot > instruction. This can happen when this instruction happens to be the > first instruction of a source line, or when the user sets the breakpoint > on a specific address. > > In the case of the SH4, the breakpoint instruction (at least the one we > use) is illegal in a delay slot. This means that, instead of triggering > the breakpoint, an illegal slot exception is raised which the user > program is expected to handle and usually results in a panic. > > In any case, even if the breakpoint were handled as normal, there is the > problem of where the program should be resumed. It is incorrect to set > the PC to the slot instruction because this will ignore the branch. The > correct thing is to set the PC to the address of the branch/slot pair - > i.e. 2 bytes back in the case of the SH4. > > There is no general way to identify a delay slot from instruction > analysis - any instruction may be preceded by data which looks like a > branch with a slot, and there is the danger of reading addresses outside > memory - so there is no way to avoid the situation in the first place. > Similarly, there is no way to identify that a breakpoint just hit was in > a slot unless you make a note of how it was hit. > > I need a way to solve this problem. Any suggestions? This is a remarkable mess. Unsurprisingly you aren't the first person to have this sort of problem, so GDB has a certain amount of support for delay slots, but MIPS at least is much friendlier: you can use the same breakpoint instruction, and there's a bit in the cause register that lets you know you were in a delay slot. When you have a symbol file, does that suffice to let you know what is code and what is data? -- Daniel Jacobowitz CodeSourcery