From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65594 invoked by alias); 29 Jan 2020 14:11:15 -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 65580 invoked by uid 89); 29 Jan 2020 14:11:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1639 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 14:11:14 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 27D5A1E5F7; Wed, 29 Jan 2020 09:11:12 -0500 (EST) Subject: Re: [PATCH 2/2,v3] [AArch64] Test handling of additional brk instruction patterns To: Luis Machado , gdb-patches@sourceware.org Cc: tankut.baris.aktemur@intel.com, alan.hayward@arm.com References: <20200115115137.17771-1-luis.machado@linaro.org> <20200115115137.17771-3-luis.machado@linaro.org> <99a220e1-36b2-0e31-ceb7-3880bf42263c@linaro.org> <23182c46-7e3c-f7e8-a91c-c8cc1049bdcd@linaro.org> <5998efd0-8cc3-afbd-ec58-4e5c4e54842b@linaro.org> From: Simon Marchi Message-ID: <8aaba7b4-4653-1f9a-1c24-c4401e111c27@simark.ca> Date: Wed, 29 Jan 2020 14:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <5998efd0-8cc3-afbd-ec58-4e5c4e54842b@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2020-01/txt/msg00933.txt.bz2 On 2020-01-29 9:09 a.m., Luis Machado wrote: > On 1/29/20 11:04 AM, Luis Machado wrote: >> >> >> On 1/29/20 11:01 AM, Simon Marchi wrote: >>> On 2020-01-29 6:30 a.m., Luis Machado wrote: >>>>>> +# Number of expected SIGTRAP's to get.  This needs to be kept in sync >>>>>> +# with the source file. >>>>>> +set expected_traps 3 >>>>>> +set keep_going 1 >>>>>> +set count 0 >>>>>> +set old_timeout $timeout >>>>>> +set timeout 10 >>>>> >>>>> Any reason you are changing the timeout?  There is nothing in the >>>>> test that >>>>> looks like it would take time. >>>>> >>>> >>>> If GDB doesn't support one of these instructions, it will be caught in >>>> an infinite loop. The reduced timeout will prevent a long wait time >>>> until we bail out. >>> >>> Ok.  The worry I have with it is that if the target board has raised >>> the timeout >>> on purpose, because it's testing with a slow target/link/emulator, >>> then this will >>> cancel it.  In this case I'd just leave the timeout as it is. >>> Normally, GDB won't >>> be broken for this test case, so it won't matter. >>> >>> Moreover, the timeout here on my x86 machine is 10 seconds by >>> default.  I just checked >>> on an AArch64 box on the compile farm, it's 10 there too.  So in which >>> case was it >>> useful to set it to 10? >>> >> >> Interesting. In my mind the default was from 30 to 60. Maybe that has >> changed over the years. If the boards are free to set it, then that is >> more desirable. >> >> I'll let it be then. > > Here's the updated patch. Thanks, that looks good to me. Simon