From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4783 invoked by alias); 18 Nov 2007 11:37:30 -0000 Received: (qmail 4775 invoked by uid 22791); 18 Nov 2007 11:37:29 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 18 Nov 2007 11:37:27 +0000 Received: (qmail 21449 invoked from network); 18 Nov 2007 11:37:24 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2007 11:37:24 -0000 From: Vladimir Prus Date: Sun, 18 Nov 2007 11:37:00 -0000 Subject: [RFA] Clarify infrun thread resumption logic. To: gdb-patches@sources.redhat.com X-TUID: 3dcdb02bacc860d1 X-Length: 2933 X-UID: 44 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711181437.18238.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00357.txt.bz2 This patch clarifies/comments a bit of infrun logic, and does not introduce any behaviour change or regressions. OK? - Volodya * infrun.c (resume): Clarify logic that decides if a single thread must be resumed. Add comments. --- gdb/infrun.c | 40 +++++++++++++++++++++++++++++++++------- 1 files changed, 33 insertions(+), 7 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index cf7aa02..85d889a 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -583,15 +583,41 @@ a command like `return' or `jump' to continue execution.")); resume_ptid = RESUME_ALL; /* Default */ - if ((step || singlestep_breakpoints_inserted_p) - && (stepping_past_singlestep_breakpoint - || (!breakpoints_inserted && breakpoint_here_p (read_pc ())))) + /* If STEP is set, it's a request to use hardware stepping + facilities. But in that case, we should never + use singlestep breakpoint. */ + gdb_assert (!(singlestep_breakpoints_inserted_p && step)); + + if (singlestep_breakpoints_inserted_p + && stepping_past_singlestep_breakpoint) { - /* Stepping past a breakpoint without inserting breakpoints. - Make sure only the current thread gets to step, so that - other threads don't sneak past breakpoints while they are - not inserted. */ + /* The situation here is as follows. In thread T1 we wanted to + single-step. Lacking hardware single-stepping we've + set breakpoint at the PC of the next instruction -- call it + P. After resuming, we've hit that breakpoint in thread T2. + Now we've removed original breakpoint, inserted breakpoint + at P+1, and try to step to advance T2 past breakpoint. + We need to step only T2, as if T1 is allowed to freely run, + it can run past P, and if other threads are allowed to run, + they can hit breakpoint at P+1, and nested hits of single-step + breakpoints is not something we'd want -- that's complicated + to support, and has no value. */ + resume_ptid = inferior_ptid; + } + if (step && breakpoint_here_p (read_pc ()) + && !breakpoint_inserted_here_p (read_pc ())) + { + /* We're stepping, have breakpoint at PC, and it's + not inserted. Most likely, proceed has noticed that + we have breakpoint and tries to single-step over it, + so that it's not hit. In which case, we need to + single-step only this thread, and keep others stopped, + as they can miss this breakpoint if allowed to run. + + The current code either has all breakpoints inserted, + or all removed, so if we let other threads run, + we can actually miss any breakpoint, not the one at PC. */ resume_ptid = inferior_ptid; } -- 1.5.3.5