From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6130 invoked by alias); 30 May 2014 12:51:44 -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 6121 invoked by uid 89); 30 May 2014 12:51:43 -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; Fri, 30 May 2014 12:51:38 +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 s4UCpZ3p026419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 May 2014 08:51:35 -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 s4UCpYQp014433; Fri, 30 May 2014 08:51:34 -0400 Message-ID: <53887ED5.5050603@redhat.com> Date: Fri, 30 May 2014 12:51: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 CC: 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> <5387BFF0.6010208@redhat.com> <20140530122253.GC4289@adacore.com> In-Reply-To: <20140530122253.GC4289@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00746.txt.bz2 On 05/30/2014 01:22 PM, Joel Brobecker wrote: >> 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? I admit I don't know what recommendation you're referring to. :-) 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? Ah, yes. We'd need the mirror treatment in bkpt_remove_location. > > 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 For 7.8, I'm thinking it's really safer to avoid resending duplicate Z0 packets to stubs that don't support conditional breakpoint evaluation on the target end. So I think we should handle the "insert" path too. BTW, did you try creating a test for the issue you discovered? I don't think we have anything that triggers this already in the tree, otherwise I think I'd have seen it with my software-single-step-on-x86 branch. > , 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... I have done that at least two or three times before, and I was never that happy with the result. This was before the patch that led to this regression, and that one and the surrounding patches were actually result of exactly wanting to modernize software single-step. :-) The main issue is that SSS breakpoints and all other breakpoints need to be inserted/removed at different times, and that is surprisingly tricky to handle. But I'm hoping/assuming the codebase is a little bit more ready now for the next attempt. My main motivation is to be able to enable non-stop without forcing displaced-stepping for all single-steps (even those that don't step over a bkpt). -- Pedro Alves