From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23733 invoked by alias); 3 Jun 2013 17:48:41 -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 23699 invoked by uid 89); 3 Jun 2013 17:48:36 -0000 X-Spam-SWARE-Status: No, score=-7.8 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; Mon, 03 Jun 2013 17:48:35 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r53HmWlH023975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Jun 2013 13:48:32 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r53HmUIM014008; Mon, 3 Jun 2013 13:48:30 -0400 Message-ID: <51ACD6ED.7040604@redhat.com> Date: Mon, 03 Jun 2013 17:48:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hui Zhu CC: Tom Tromey , gdb-patches@sourceware.org, Keith Seitz , Yao Qi Subject: Re: [RFC] PR 15075 dprintf interferes with "next" References: <1361192891-29341-1-git-send-email-yao@codesourcery.com> <8738wpd3qe.fsf@fleche.redhat.com> <5176C14B.6010603@redhat.com> <51774714.9060306@codesourcery.com> <51969A92.80003@redhat.com> <519CBE2B.7060007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00025.txt.bz2 On 06/03/2013 05:06 AM, Hui Zhu wrote: > Ping http://sourceware.org/ml/gdb-patches/2013-05/msg00958.html > As this exposes the non-stop racy failure, we should fix it that one first. Failing that, we should kfail or skip the test with remote targets. Let's consider the latter option later if we don't manage to address the race timely. As I said on: http://sourceware.org/ml/gdb-patches/2013-05/msg01111.html I'm investigating this. I have a prototype patch, but I need a bit more to handle some details, like what to do with signal catchpoints when we find threads had been stopped with a signal (I'm currently thinking of skipping the catchpoints). I'm composing a test to exercise/expose this kind of stuff, for a better RFC. -- Pedro Alves