From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12699 invoked by alias); 22 Oct 2006 19:47:24 -0000 Received: (qmail 12689 invoked by uid 22791); 22 Oct 2006 19:47:23 -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; Sun, 22 Oct 2006 19:47:20 +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 k9MJlHG2013390; Sun, 22 Oct 2006 21:47:17 +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 k9MJlHa1017621; Sun, 22 Oct 2006 21:47:17 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k9MJlGAw011372; Sun, 22 Oct 2006 21:47:16 +0200 (CEST) Date: Sun, 22 Oct 2006 19:47:00 -0000 Message-Id: <200610221947.k9MJlGAw011372@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: andrew.stubbs@st.com CC: mark.kettenis@xs4all.nl, gdb@sourceware.org In-reply-to: <45388BF9.90604@st.com> (message from Andrew STUBBS on Fri, 20 Oct 2006 09:42:33 +0100) Subject: Re: Breakpoints in delay slots References: <453608FC.2040201@st.com> <200610191951.k9JJpV7W023082@elgar.sibelius.xs4all.nl> <45388BF9.90604@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/msg00195.txt.bz2 > Date: Fri, 20 Oct 2006 09:42:33 +0100 > From: Andrew STUBBS > > > 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(). > > How does one fix the problem that GDB doesn't associate the trap with > the breakpoint? Not only will it tell the user there was an unexpected > trap, ignore any conditions or commands, and show the source location as > somewhere else, but it won't take any measures to avoid the breakpoint > on the restart. Ah, looks like I wasn't quite clear about this. You'll have your stub (or OS kernel) report the address of the delay slot as where it stopped (such that gdb will do the right thing for hitting the breakpoint). But the stub will remember that it actually hit a breakpoint in a delay slot. Later when gdb asks the stub to continue, you make it back up to the address of the branch instruction before you let it run again. Mark