From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14829 invoked by alias); 31 Aug 2016 17:50: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 14813 invoked by uid 89); 31 Aug 2016 17:50:33 -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,URIBL_RED autolearn=ham version=3.3.2 spammy=palvesredhatcom, palves@redhat.com, queued 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; Wed, 31 Aug 2016 17:50:23 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 A4CBB345AB7; Wed, 31 Aug 2016 17:50:22 +0000 (UTC) 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 u7VHoLGL032046; Wed, 31 Aug 2016 13:50:22 -0400 Subject: Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer To: Antoine Tremblay , gdb-patches@sourceware.org References: <20160831171406.24057-1-antoine.tremblay@ericsson.com> <20160831171406.24057-2-antoine.tremblay@ericsson.com> From: Pedro Alves Message-ID: Date: Wed, 31 Aug 2016 17:50: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: <20160831171406.24057-2-antoine.tremblay@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-08/txt/msg00331.txt.bz2 On 08/31/2016 06:14 PM, Antoine Tremblay wrote: > This patch enables range stepping to be done in GDBServer with an ARM > target. > > There is one problem however with the gdb.threads/non-stop-fair-events.exp > test. > > Since single stepping is done in software and that displaced stepping is > not supported, threads end up hitting each others breakpoints and the main > thread can't make any progress passed a number of threads on my system. > > Thus we get: > FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=5: thread 1 > broke out of loop (timeout) > > Note that even letting it go an hour doesn't help so bumping the timeout > is out of the question. > > I'm not sure what to do about this one ? kfail ? ideas ? Hmm, this is exactly the sort of problem the test is meant to catch, and the reason we do event thread randomization: # Test that GDB in non-stop mode gives roughly equal priority to # events of all threads. Why does it work without range stepping, but not with? E.g., back when we did: commit 1ed415e2b9b985aac087c35949d0e1e489ab496d Author: Pedro Alves AuthorDate: Wed Sep 16 15:51:36 2015 +0100 non-stop-fair-events.exp slower on software single-step && !displ-step targets On software single-step targets that don't support displaced stepping, threads keep hitting each other's single-step breakpoints, and then GDB needs to pause all threads to step past those. The end result is that progress in the main thread will be slower and it may take a bit longer for the signal to be queued. This patch bumps the timeout on such targets. gdb/testsuite/ChangeLog: 2015-09-16 Pedro Alves Sandra Loosemore [...] ... the test always managed to complete on sss && !displ-step targets. Thanks, Pedro Alves