From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24314 invoked by alias); 7 Jun 2004 15:08:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24297 invoked from network); 7 Jun 2004 15:08:53 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Jun 2004 15:08:53 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i57F8mi7011641 for ; Mon, 7 Jun 2004 11:08:48 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i57F8m031519; Mon, 7 Jun 2004 11:08:48 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EE5372B9D; Mon, 7 Jun 2004 11:08:46 -0400 (EDT) Message-ID: <40C484FE.5080702@gnu.org> Date: Mon, 07 Jun 2004 15:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: STEP_SKIPS_DELAY question, sort of References: <40AE38D0.7010204@axis.com> <40AE659A.90207@gnu.org> <40B1BD1B.4090300@axis.com> <40B23BB2.6070001@gnu.org> <40B33399.3090803@axis.com> <40B3B742.50007@gnu.org> <40B465E7.7050702@axis.com> <40C45B95.9050309@axis.com> <40C46290.9000402@axis.com> <40C46919.2060802@axis.com> In-Reply-To: <40C46919.2060802@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00123.txt.bz2 > Orjan Friberg wrote: > >> >> Gah. Please ignore the previous patch (and sorry); what I posted only works when doing a continue when stopped at the branch instruction. Doing a step (which leaves us in the delay slot) followed by another step (or continue for that matter) prematurely inserts the breakpoint. > > > Ok, second try (still concept patch though): the change in proceed is needed for when we resume from the delay slot - in that case we need to single-step again before re-inserting the breakpoint (similar to the MIPS case). The change in handle_inferior_event (and I'll happily agree it's far more questionable) is needed for when we resume at the branch instruction itself. Comments? Can this new mechanism somehow superseed STEP_SKIPS_DELAY - it seems to be the exact oposite but there could be common ground here. > Index: infrun.c > =================================================================== > RCS file: /cvs/src/src/gdb/infrun.c,v > retrieving revision 1.156 > diff -u -p -r1.156 infrun.c > --- infrun.c 11 May 2004 23:30:31 -0000 1.156 > +++ infrun.c 7 Jun 2004 12:59:10 -0000 > @@ -748,6 +748,14 @@ proceed (CORE_ADDR addr, enum target_sig > && breakpoint_here_p (read_pc () + 4) > && STEP_SKIPS_DELAY (read_pc ())) > oneproc = 1; > + > + /* If we stepped into a delay slot, and the preceding instruction > + will be re-executed when resuming, step again before re-inserting > + the breakpoint. */ > + if (STEP_SKIPS_IN_DELAY_P > + && " > + && STEP_SKIPS_IN_DELAY (read_pc ())) > + oneproc = 1; > } > else > { They both seem to be asking the question: "given PC and a list of breakpoints, should the inferior be h/w single-stepped?". That would mean pushing the alternative: breakpoint_here_p (read_pc () - 2) breakpoint_here_p (read_pc () + 4) calls into that architecture method. > @@ -1975,7 +1983,17 @@ handle_inferior_event (struct execution_ > /* Don't even think about breakpoints if just proceeded over a > breakpoint. */ > if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected) > - bpstat_clear (&stop_bpstat); > + { > + bpstat_clear (&stop_bpstat); > + > + /* If we stepped into a delay slot, and the preceding instruction > + will be re-executed when resuming, step again before re-inserting > + the breakpoint. */ > + if (STEP_SKIPS_IN_DELAY_P > + && breakpoint_here_p (read_pc () - 2) > + && STEP_SKIPS_IN_DELAY (read_pc ())) > + ecs->another_trap = 1; > + } > else > { > /* See if there is a breakpoint at the current PC. */ > I'm just not sure how this bit of logic should fit in. I'm guessing its the second half of the state m/c sequence: 1. step off breakpoint at `PC' 2. step through delay Andrew