From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33291 invoked by alias); 29 Jun 2016 20:10:34 -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 33281 invoked by uid 89); 29 Jun 2016 20:10:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=agent 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; Wed, 29 Jun 2016 20:10:27 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E424CB0CE5; Wed, 29 Jun 2016 20:10:25 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5TKAOYN007848; Wed, 29 Jun 2016 16:10:25 -0400 Subject: Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7 To: Antoine Tremblay References: <1465476975-25062-1-git-send-email-antoine.tremblay@ericsson.com> <0d896cd9-f857-db41-fdb1-2ebde0eeeb01@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <259cec78-8993-e31a-2d8e-d16d96a34a7a@redhat.com> Date: Wed, 29 Jun 2016 20:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00527.txt.bz2 On 06/29/2016 08:15 PM, Antoine Tremblay wrote: > > Pedro Alves writes: > OK, I guess I have to find a way to interrupt it, in my case using a > circular buffer, trying c& and interrupt as no effect or C-c with > continue... Sounds like a gdbserver bug. :-/ You should always be able to interrupt. Seems like what you'd get if the signal ends up in the pending queue, but is then never reported, for whatever reason. If this is non-stop, could also be related to stopping with SIGSTOP, which requires special treatment. Try with "kill -SIGINT" in the terminal too. > > I'll try a less tight loop and check that's it's in the traced code but > not in the usleep... > > In the meantime it made me test arm fast tracepoints with a thight loop > like that and it crashes the inferiror when the agent buffer is full :( Nice... :-P > > I'll fix that 1st.. Thanks, Pedro Alves