From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28417 invoked by alias); 30 May 2014 12:22:58 -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 28400 invoked by uid 89); 30 May 2014 12:22:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 30 May 2014 12:22:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3A67611627D; Fri, 30 May 2014 08:22:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SCRg7ldjcwF3; Fri, 30 May 2014 08:22:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0F5BF116235; Fri, 30 May 2014 08:22:53 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CD3DD4001D; Fri, 30 May 2014 05:22:53 -0700 (PDT) Date: Fri, 30 May 2014 12:22:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFA/7.8] user breakpoint not inserted if software-single-step at same location Message-ID: <20140530122253.GC4289@adacore.com> References: <1401394280-14999-1-git-send-email-brobecker@adacore.com> <5387BFF0.6010208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5387BFF0.6010208@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-05/txt/msg00745.txt.bz2 Hi Pedro, Thanks for the super quick review! > Async/background execution breaks that assumption though. Hmmm, you are right. I had a feeling that this assumption was going to come back to bite us one day. I didn't realize that it was going to be today! ;-) > 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. [...] > 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. It seems to me that we'd need to merge your initial recommendation into your summary above, right? Otherwise, wouldn't we fail in the async example you provided? Actually, wouldn't it fail regardless? Even if we inserted the SSS breakpoint, when the user deletes his breakpoints, since the breakpoint chain doesn't know about the SSS breakpoint, wouldn't it remove our SSS breakpoint insn? I am wondering whether the simpler approach that you initially suggested, which is to just handle the issue in the "remove" path for 7.8 wouldn't be a little safer, while we also look at actually enhancing SSS breakpoints via the normal breakpoint chain. I am wondering what's going to be needed for that... WDYT? Thanks! -- Joel