From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4387 invoked by alias); 23 Nov 2007 20:10:28 -0000 Received: (qmail 4379 invoked by uid 22791); 23 Nov 2007 20:10:28 -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; Fri, 23 Nov 2007 20:10:24 +0000 Received: (qmail 12342 invoked from network); 23 Nov 2007 20:10:22 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Nov 2007 20:10:22 -0000 From: Vladimir Prus Date: Fri, 23 Nov 2007 20:10:00 -0000 Subject: [RFA] Don't ignore consecutive breakpoints. To: gdb-patches@sources.redhat.com X-TUID: 29653dc25bd1b0c3 X-Length: 1627 X-UID: 61 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711232310.17854.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/msg00437.txt.bz2 Suppose we have two breakpoints at two consecutive addresses, and we do "step" while stopped on the first breakpoint. GDB testsuite has a test (consecutive.exp) that the second breakpoint will be hit a reported, and the test passes, but the code directly contradicts, saying: /* Don't even think about breakpoints if just proceeded over a breakpoint. */ if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected) { if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n"); bpstat_clear (&stop_bpstat); } what's happening is that we indeed ignore the breakpoint, and try to step further. However ecs->another_trap is not set, so we step with breakpoints inserted, and immediately hit the now-inserted breakpoint. Therefore, I propose to remove that code. On x86, the below patch causes a single test outcome change: -KFAIL: gdb.base/watchpoint.exp: next after watch x (PRMS: gdb/38) +PASS: gdb.base/watchpoint.exp: next after watch x The test is for a breakpoint set on a line that also triggers a watchpoint. The outcome changed because we now do check breakpoints after stepping over breakpoint. The target does not have any watchpoint stop address, so we read watched value, and find that in indeed has changed. OK? - Volodya * infrun.c (handle_inferior_event): Don't ignore beakpoints if trap_expected is set. --- gdb/infrun.c | 23 ++++++----------------- 1 files changed, 6 insertions(+), 17 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index 85d889a..feff6aa 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1983,23 +1983,12 @@ handle_inferior_event (struct execution_control_state *ecs) return; } - /* Don't even think about breakpoints if just proceeded over a - breakpoint. */ - if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected) - { - if (debug_infrun) - fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n"); - bpstat_clear (&stop_bpstat); - } - else - { - /* See if there is a breakpoint at the current PC. */ - stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid); - - /* Following in case break condition called a - function. */ - stop_print_frame = 1; - } + /* See if there is a breakpoint at the current PC. */ + stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid); + + /* Following in case break condition called a + function. */ + stop_print_frame = 1; /* NOTE: cagney/2003-03-29: These two checks for a random signal at one stage in the past included checks for an inferior -- 1.5.3.5