From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24136 invoked by alias); 29 May 2014 17:47:56 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 24104 invoked by uid 55); 29 May 2014 17:47:55 -0000 From: "brobecker at adacore dot com" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/7143] Watchpoint does not trigger when first set Date: Thu, 29 May 2014 17:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: brobecker at adacore dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: palves at redhat dot com X-Bugzilla-Target-Milestone: 7.8 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00329.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=7143 --- Comment #15 from brobecker at adacore dot com --- > Odd. It's as if the breakpoint at 0x10000a28 never got inserted at all. I am on it, but just to keep you entertained... :-) It appears to be exactly what's going on. I am wondering if that may be related to the fact that we have a user breakpoint at the same address as one of the SSS breakpoints. That's all a guess, since I haven't really looked into details at which breakpoint insertions correspond to what. But notice how we insert the breakpoint at 0x10000a28 twice? (gdb) c >>> First, we insert the user breakpoints (the second one is an internal >>> breakpoint on __pthread_init). The first user breakpoint is not >>> inserted as we need to step out of it first. target_insert_breakpoint (0x0000000010000a28, xxx) = 0 target_insert_breakpoint (0x00000000d03f3800, xxx) = 0 >>> Then we proceed with the step-out-of-breakpoint... infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 15335610] at 0x10000a24 >>> That's when we insert the SSS breakpoints... target_insert_breakpoint (0x0000000010000a28, xxx) = 0 target_insert_breakpoint (0x00000000100009ac, xxx) = 0 >>> ... then let the inferior resume... target_resume (15335610, continue, 0) infrun: wait_for_inferior () target_wait (-1, status, options={}) = 15335610, status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: target_wait (-1, status) = infrun: 15335610 [process 15335610], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x100009ac >>> At this point, we stopped at the second SSS breakpoint... target_stopped_by_watchpoint () = 0 >>> That must be us removing the SSS breakpoints... target_remove_breakpoint (0x0000000010000a28, xxx) = 0 target_remove_breakpoint (0x00000000100009ac, xxx) = 0 target_stopped_by_watchpoint () = 0 >>> We find that we're not done, so we resume.... infrun: no stepping, continue >>> And thus insert the userr breakpoints again, except we're not >>> inserting the second breakpoint?!? I bet this is because we think >>> it's still inserted, but in fact it got removed by the SSS bp >>> removal earlier. target_insert_breakpoint (0x0000000010000a24, xxx) = 0 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 15335610] at 0x100009ac target_resume (-1, continue, 0) infrun: prepare_to_wait target_wait (-1, status, options={}) = 15335610, status->kind = exited, status = 2 -- You are receiving this mail because: You are on the CC list for the bug.