From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4380 invoked by alias); 9 Jun 2004 16:00:26 -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 4345 invoked from network); 9 Jun 2004 16:00:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Jun 2004 16:00:24 -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 i59G0Oi7022609 for ; Wed, 9 Jun 2004 12:00:24 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i59G0N026622; Wed, 9 Jun 2004 12:00:23 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A4CD22B9D; Wed, 9 Jun 2004 12:00:17 -0400 (EDT) Message-ID: <40C73411.9060708@gnu.org> Date: Wed, 09 Jun 2004 16:00: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> <40C484FE.5080702@gnu.org> <40C6DCF9.2060700@axis.com> In-Reply-To: <40C6DCF9.2060700@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00178.txt.bz2 > Andrew Cagney wrote: > >> >> Can this new mechanism somehow superseed STEP_SKIPS_DELAY - it seems to be the exact oposite but there could be common ground here. > > > [proceed patch snipped] > >> 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. > > > Agreed. (STEP_SKIPS_IN_DELAY was just to have something to put in the patch.) > > What about using the name STEP_SKIPS_DELAY for both, and introducing a DELAY_SIZE which would return a positive value (meaning the diff from the current pc to the delay slot) or a negative (meaning the diff from the delay slot to the instruction preceding it)? Or does the word "size" imply an absolute value? If the: >> breakpoint_here_p (read_pc () - 2) and >> breakpoint_here_p (read_pc () + 4) logic is moved to the per-architecture STEP_SKIPS_DELAY I don't think DELAY_SIZE is needed. I also think this needs a new macro name that better reflects what the test is doing. But I've no good ideas :-/ (SINGLE_STEP_THROUGH_DELAY (pc)?) > [handle_inferior_event patch snipped] > >> 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 > > > Unless I missed something on the way, the procedure when doing a continue from a > breakpoint that sits on the branch instruction is this: > > 1. proceed decides it needs to step once before continuing (since read_pc () == stop_pc && breakpoint_here_p (read_pc ())) > 2. resume is called, with step = 1 > 3. target is single-stepped > 4. handle_inferior_event is called (at which point we're stopped in the delay slot) yes (step off breakpoint at `PC') > It is at this point we need to single-step again (before inserting breakpoints again), so I set ecs->another_trap. Then: > > 5. keep_going is called, and since ecs->anther_trap is set, it doesn't call insert_breakpoints. > 6. resume is called again, with step = 1 > 7. target is single-stepped > 8. handle_inferior_event is called again (but doesn't set ecs->another_trap this time) > 9. keep_going is called, and inserts the breakpoints again ok (step through delay) > I can't say where would be a better place to put the decision of whether to single-step again. Any suggestions? Can a simple, separate, more explicit logic like: if (we just did a step and STEP_SKIPS_DELAY (pc)) set up for another step return; work? The [handle_inferior_event patch snipped] was nested within other logic and that's not good from a readability / maintainability point of view. Andrew