From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19385 invoked by alias); 26 Apr 2013 17:50:32 -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 19359 invoked by uid 89); 26 Apr 2013 17:50:32 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 26 Apr 2013 17:50:32 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3QHoV1B000739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Apr 2013 13:50:31 -0400 Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3QHoU3I026255 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 13:50:30 -0400 Message-ID: <517ABE65.1040809@redhat.com> Date: Fri, 26 Apr 2013 20:45:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org ml" Subject: Re: [RFA/testsuite] Cleanup pending breakpoints References: <517716B5.7050406@redhat.com> <5177EDAF.6030107@redhat.com> <517986D9.3060607@redhat.com> <517ABD12.9020506@redhat.com> In-Reply-To: <517ABD12.9020506@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00820.txt.bz2 On 04/26/2013 10:44 AM, Pedro Alves wrote: > If in the end, there's no use in the tree for an "allow-pending" > option that allows pending but doesn't fail with a regular > non-pending breakpoint, in addition to a new "pending" option that > _requires_ pending, then I'd rather eliminate "allow-pending". Right, that's what I meant -- remove "allow-pending" and add "pending". I suggest for the immediate time, we/I introduce "pending" (i.e, fail if regular BP set), and then we/I can go back and take a look at all the users of allow-pending and ascertain whether they would work (or were supposed to work) if a normal breakpoint was set. From the dozen cases or two that I've already looked at (or written), all were really of the required type not optional type, i.e., the test was written specifically for a pending breakpoint; a regular breakpoint would break the test. Keith