From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11396 invoked by alias); 1 Sep 2016 15:59:29 -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 11386 invoked by uid 89); 1 Sep 2016 15:59:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=witness 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; Thu, 01 Sep 2016 15:59:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 3ECC0A13E3; Thu, 1 Sep 2016 15:59:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u81FxOdp011424; Thu, 1 Sep 2016 11:59:24 -0400 Subject: Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer To: Antoine Tremblay , Yao Qi References: <20160831171406.24057-1-antoine.tremblay@ericsson.com> <20160831171406.24057-2-antoine.tremblay@ericsson.com> <3fdb7193-60c7-49c9-ccf5-bc040aa157ea@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 01 Sep 2016 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00020.txt.bz2 On 09/01/2016 04:21 PM, Antoine Tremblay wrote: > > Pedro Alves writes: > >> On 08/31/2016 08:14 PM, Antoine Tremblay wrote: >> >>> I'm sorry I can't be more helpful at the moment but I wanted to post >>> this issue before I have to leave for a while. >> >> Understood. Does enabling range stepping unblock something else? > > It would unblock ARM tracepoints, as per Yao's requirements... Tracepoints make gdbserver single-step and then not report the event to gdb, so I do see the parallel with range-stepping. Throwing while-stepping into the equation would make it even more clear. But maybe we can paralyze? If enabling tracepoints without range stepping causes no known regression, but enabling range stepping with no tracepoints causes regressions, seems to me like we could put tracepoints in first, and fix whatever range stepping problems in parallel. Skipping the test sounds far from ideal to me, since the test has a tendency of catching problems. Witness patch 1/2 in this very series, for example... Thanks, Pedro Alves