From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13011 invoked by alias); 29 May 2014 23:17:42 -0000 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 Received: (qmail 13000 invoked by uid 89); 29 May 2014 23:17:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 May 2014 23:17:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4TNH6KX006501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 May 2014 19:17:06 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4TNH46v025021; Thu, 29 May 2014 19:17:05 -0400 Message-ID: <5387BFF0.6010208@redhat.com> Date: Thu, 29 May 2014 23:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [RFA/7.8] user breakpoint not inserted if software-single-step at same location References: <1401394280-14999-1-git-send-email-brobecker@adacore.com> In-Reply-To: <1401394280-14999-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00738.txt.bz2 On 05/29/2014 09:11 PM, Joel Brobecker wrote: > Hello, > > with the following code... > > 12 Nested; -- break #1 > 13 return I; -- break #2 > 14 end; > > (line 12 is a call to function Nested) > > ... we have noticed the following errorneous behavior on ppc-aix, "erroneous" > This patch does make one assumption, however, which is the fact > that user breakpoints get inserted before software single-step > breakpoints. I think this is a fair assumption, as software > single-step breakpoints get created as part of the target-step > operation (resume with step=1), which logically can only happen > after we've inserted all breakpoints. Async/background execution breaks that assumption though. E.g., say you do: (gdb) b *0xsame_addr_as_sss_bkpt (gdb) s & (gdb) del That "del" runs while the target is single-stepping. And it might just delete the breakpoint that was at the same address as a single-step breakpoint, before the single-step breakpoint traps or gdb collects the trap. If you try that on native GNU/Linux, it'll fail because then GDB can't poke at memory while the program is running. You can still trigger it with using two threads: (gdb) b *0xsame_addr_as_sss_bkpt (gdb) set scheduler-locking on (gdb) thread 1 (gdb) s & (gdb) thread 2 // this thread is stopped, so we can poke at memory. (gdb) del That's why I thought it'd be easier to do this in the "remove" path. We can still bypass actually inserting the sss breakpoint in the "insert" path if there's already another breakpoint there, but we'll need to create/clone the location and its shadow buffer, and then still handle the issue in the "remove" path. I'm now thinking that indeed we should implement that optimization, but not for efficiency (this being a corner case, it's doubtful it matters), but to cater for remote targets that might not handle duplicate Z0 packets well. They're supposed to be handled in an idempotent manner, but even GDBserver had related issues recently. Oh, _but_! If the target supports breakpoint evaluating breakpoint conditions itself (target_supports_evaluation_of_breakpoint_conditions), such as GDBserver, then we _need_ to send the duplicate software single-step Z0 breakpoint, in case the non-sss breakpoint that is already inserted at the same address was conditional, otherwise the target is only going to report the breakpoint hit if the non-sss breakpoint's condition evaluates true, while we need the sss breakpoint to be unconditional. (In this case we know for sure that the target knows what to do with the duplicate Z0 packets, it's a requirement of the feature.) In sum, in the "insert" path: - if !target_supports_evaluation_of_breakpoint_conditions; then optimize out the sss breakpoint if there's already a non-sss breakpoint inserted at the same address. else make sure to resend/reinsert the breakpoint sss breakpoint, even if there's already a non-sss in place, in case that other breakpoint was conditional. fi And in the "remove" path: - if there's still a non-sss breakpoint inserted at the same address, then don't actually remove the breakpoint off of the target, just wipe it from gdb's list. > Also, due to the nature of the regression (compared to 7.7), I think > we should wait for a resolution of this issue before creating the > gdb 7.8 release branch. I agree. Thanks, -- Pedro Alves