From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3067 invoked by alias); 19 Oct 2006 19:51:40 -0000 Received: (qmail 3053 invoked by uid 22791); 19 Oct 2006 19:51:40 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Oct 2006 19:51:36 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k9JJpXrS029162; Thu, 19 Oct 2006 21:51:33 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k9JJpW7o012336; Thu, 19 Oct 2006 21:51:32 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k9JJpV7W023082; Thu, 19 Oct 2006 21:51:31 +0200 (CEST) Date: Thu, 19 Oct 2006 19:51:00 -0000 Message-Id: <200610191951.k9JJpV7W023082@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: andrew.stubbs@st.com CC: gdb@sourceware.org In-reply-to: <453608FC.2040201@st.com> (message from Andrew STUBBS on Wed, 18 Oct 2006 11:59:08 +0100) Subject: Re: Breakpoints in delay slots References: <453608FC.2040201@st.com> 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/msg00141.txt.bz2 > Date: Wed, 18 Oct 2006 11:59:08 +0100 > From: Andrew STUBBS > > 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. This is because the SH4 can have "data words" in the instruction stream isn't it? > 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? As Daniel already mentioned this does sound pretty similar to what MIPS does. There is however an important difference in that MIPS will actually generate a trap on the branch instruction and set a flag in a register to indicate that the trap actually occured in the delay slot. My solution would be to emulate what MIPS does. So in the exception handler for the illegal slot exception, check whether you've hit a breakpoint. If so report SIGTRAP back to GDB and make sure that if you get a continue from GDB, you back up the instruction pointer to the branch instruction preceding the delay slot. This will require you to implement sh_single_step_through_delay(). Incidentally we're currently porting OpenBSD to the SH4, and my current plan for OpenBSD/sh is to do what I sketched above. Mark