From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79550 invoked by alias); 6 Mar 2015 16:43: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 79541 invoked by uid 89); 6 Mar 2015 16:43:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Mar 2015 16:43:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t26GhrCF006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Mar 2015 11:43:53 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t26GhpEM016895; Fri, 6 Mar 2015 11:43:52 -0500 Message-ID: <54F9D947.6090905@redhat.com> Date: Fri, 06 Mar 2015 16:43:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [pushed 1/2] PR gdb/18002: Fix reinsert of a permanent breakpoints References: <1425598969-7666-1-git-send-email-palves@redhat.com> <1425598969-7666-2-git-send-email-palves@redhat.com> <86d24mi4ei.fsf@gmail.com> In-Reply-To: <86d24mi4ei.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00174.txt.bz2 On 03/06/2015 02:31 PM, Yao Qi wrote: > Your fix looks right to me, although I am testing a different one, in > which bp_location_has_shadow returns false if bl->permanent is true. > Anyway, Thanks for fixing this bug, Pedro. Yeah, I also considered that, though we'd likely end up needing more special casing in other places: the setting of shadow_len before the read and the shadow_contents afterwards looked so bogus that I thought that even if we fixed this some other way, we should still do what I had done. And then I was seeing more fundamental brokenness with permanent breakpoints and stopped at that point. The other issues I identified were: - If the user manually changes memory at the permanent breakpoint address, we should really write to the shadow buffer, not to memory, and clear the permanent bp flag. We don't do the latter. Likewise, if the user writes an int3 manually where a breakpoint is already set, we should mark the breakpoint as permanent. I suspect that filling the shadow buffer (with a software breakpoint) immediately when we detect the program breakpoint (bp_loc_is_permanent's caller) would make things simpler, considering targets where the breakpoint is longer than one byte, and writes to only parts of the breakpoint. - I also considered completely getting rid of the ->permanent flag, and then in places where we need to know whether we stopped at one (to step over it), we would check if the shadow contains a software breakpoint. The case that gave me pause was hardware breakpoints on top of a permanent bp, which don't have a shadow. Or we could even always check if there's a program breakpoint at PC that we should skip by manually advancing the PC, even if there's no user breakpoint on top... The trick will be to try to avoid the extra memory read. But maybe either that doesn't matter in practice, given that we should limit that for when the program had stopped for a SIGTRAP, and, SIGTRAP isn't set to "pass", and the PC it still the PC the thread had when it stopped. Hmm... Thanks, Pedro Alves