From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OTM2CYDNxGpZuAMAWB0awg (envelope-from ) for ; Tue, 06 Oct 2026 06:29:20 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=vrany.io header.i=@vrany.io header.a=rsa-sha256 header.s=protonmail header.b=XH+yeM7G; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1D7831E051; Tue, 06 Oct 2026 06:29:20 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 91C9C1E04E for ; Tue, 06 Oct 2026 06:29:18 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E9C564BB589A for ; Tue, 6 Oct 2026 10:29:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9C564BB589A Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=vrany.io header.i=@vrany.io header.a=rsa-sha256 header.s=protonmail header.b=XH+yeM7G Received: from mail-10625.protonmail.ch (mail-10625.protonmail.ch [79.135.106.25]) by sourceware.org (Postfix) with ESMTPS id 1A9634BB3BD7 for ; Tue, 6 Oct 2026 10:28:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A9634BB3BD7 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=vrany.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrany.io ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1A9634BB3BD7 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=79.135.106.25 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791282532; cv=none; b=vD6R7UQLfDPzPhrICDF+rSfU15ZGbWmS2epxvYtwFzfncaKOeD00j84ijcHsB9sjUijqF20M2B4+I/2I+zXk02OjhP7hkC89RsIAFd1tDr12OVTdOCXWEbbRCBQeLnH3VsypMU/Pv+9mb7i4Q4vDI4NHi1zkMQTmPdGz8tLzvSU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791282532; c=relaxed/simple; bh=eZPC5aghjtEf3DFhsfs1pfDzHKmiieAub8W/Z9puAc0=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=J+lKdE4XD6KCsRcvLUL9AqnEskts8W3Ify9uI4tu2V2XPCMvFINYIIkmi+imKAiSqUfa08ZCaEftwJ9EiBQEvLfuWewquoPTDlopf6ReAHI6MFwNXl37yZyMVCwkHtYKpj3kompEN5E3pggUwv8OpZIv/awWpxOSZsnfDWjIFsE= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=vrany.io header.i=@vrany.io header.a=rsa-sha256 header.s=protonmail header.b=XH+yeM7G DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A9634BB3BD7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrany.io; s=protonmail; t=1791282530; x=1791541730; bh=eZPC5aghjtEf3DFhsfs1pfDzHKmiieAub8W/Z9puAc0=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XH+yeM7GNoVnn+208EURtNq5kH9H4lmPNUAZrwT9sNCWPshDjHaHhe9T+efUV22sq W3ddOi9ASeAuKDddcHL1NpydkLtMcV9JW0Vx+IFgGbvMxMMmoEgfTMPU2YJMERkAp+ v22nqCY5OMWsPk/mZwwnOJIY7ADEHNc1J7sYR+Ffwe4n0bCbPe54vSyrbQd5ko8Y5H DCNJX6ebAjb8ojhUB/8pH7NsBWttK7kGBBn91m1i0ezaBuFi4B3DAGaIw6bUG96j/+ PcOKRXCwxrM9mI3twXCyCsUB4oZkFmmWEyWgjlCXYDA+AhpSddMsvxgpaZphf3rHAj Q9hc+VAiZWJSA== Date: Tue, 06 Oct 2026 10:28:45 +0000 To: Simon Marchi , gdb-patches@sourceware.org From: Jan Vrany Subject: Re: [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests Message-ID: <9737a599bddf506c310d2b685f638ef6094a5ea2.camel@vrany.io> In-Reply-To: <4da1ade7-98ec-4d80-94a3-079fe0bb72b4@simark.ca> References: <20261005095158.1186551-1-jan@vrany.io> <4da1ade7-98ec-4d80-94a3-079fe0bb72b4@simark.ca> Feedback-ID: 40767693:user:proton X-Pm-Message-ID: d2353a57e8e47e6c368cc50b8f7b19ffc49458b3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Mon, 2026-10-05 at 10:03 -0400, Simon Marchi wrote: > On 10/5/26 5:52 AM, Jan Vrany wrote: > > When running tests on some really slow targets, I got timeout in > > gdb.base/funcargs.exp and gdb.base/completion.exp. The usual remedy I > > use is to set timeout to higher value in site.exp. >=20 > I'd be curious to know which tests in those files exactly, see if we can > improve either the test or GDB. On my Vision5 RISC-V board I saw completion tests failing: Running /home/jv/Projects/gdb/master/build/riscv64-linux-gnu/gdb/testsuite/= ../../../../gdb/testsuite/gdb.base/completion.exp ... FAIL: gdb.base/completion.exp: complete 'p ' (timeout) FAIL: gdb.base/completion.exp: complete 'info t foo' (timeout) FAIL: gdb.base/completion.exp: complete 'info t' (timeout) FAIL: gdb.base/completion.exp: complete 'info t ' (timeout) FAIL: gdb.base/completion.exp: complete 'info asdfgh' (timeout) FAIL: gdb.base/completion.exp: complete 'info asdfgh ' (timeout) FAIL: gdb.base/completion.exp: complete 'info' (timeout) FAIL: gdb.base/completion.exp: complete 'info ' (timeout) FAIL: gdb.base/completion.exp: complete (2) 'info ' (timeout) FAIL: gdb.base/completion.exp: complete 'help info wat' (timeout) FAIL: gdb.base/completion.exp: complete 'p "break1' (timeout) FAIL: gdb.base/completion.exp: complete 'p 'arg' (timeout) FAIL: gdb.base/completion.exp: complete (2) 'p 'arg' (timeout) FAIL: gdb.base/completion.exp: complete 'handle signal' (timeout) FAIL: gdb.base/completion.exp: complete 'handle keyword' (timeout) FAIL: gdb.base/completion.exp: complete help aliases (timeout) FAIL: gdb.base/completion.exp: complete 'p no_var_named_this-arg' (timeout) FAIL: gdb.base/completion.exp: complete (2) 'p no_var_named_this-arg' (time= out) FAIL: gdb.base/completion.exp: complete (2) 'p no_var_named_this-' (timeout= ) FAIL: gdb.base/completion.exp: complete 'p values[0].a' (timeout) FAIL: gdb.base/completion.exp: complete 'p values[0] . a' (timeout) FAIL: gdb.base/completion.exp: complete 'p &values[0] -> a' (timeout) FAIL: gdb.base/completion.exp: completion of field in anonymous union It think it is really just the CPU being slow by today's standards. Interestingly, I cannot reproduce gdb.base/funcargs.exp failures on any of my machines though I'm pretty sure I've seen them. Perhaps they were overloaded or some NFS issue. Anyways, I think it would be better to use with_timeout_factor there too just in case. >=20 > > However this does not help in case of aforementioned tests because they > > set timeout to fixed value, regardless of whether the timeout has been > > increased or not, causing them to fail on some of my machines. > >=20 > > This commit fixes the problem by using with_timeout_factor. > >=20 > > Since with_timeout_factor wraps large chunks of code, I decided not > > to reformat (indent) it to make the patch easier to read and to > > avoid "noise" when git-blaming. >=20 > I would suggest do the re-indent.=C2=A0 I find readability of current cod= e > more important than hypothetic git-blamability.=C2=A0 Plus, I believe tha= t > anyone doing any serious git-blaming should use a better tool than plain > bit-blame, allowing to easily jump over uninteresting commits (for > instance, I use "tig blame" and jumping over an uninteresting commit is > one keystroke). Fair point - will reformat. Thanks! >=20 > > --- > > =C2=A0gdb/testsuite/gdb.base/completion.exp |=C2=A0 6 +++++- > > =C2=A0gdb/testsuite/gdb.base/funcargs.exp=C2=A0=C2=A0 | 11 +++++++---- > > =C2=A02 files changed, 12 insertions(+), 5 deletions(-) > >=20 > > diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.= base/completion.exp > > index 44cf649d5b6..f145f084999 100644 > > --- a/gdb/testsuite/gdb.base/completion.exp > > +++ b/gdb/testsuite/gdb.base/completion.exp > > @@ -61,7 +61,8 @@ if {![runto_main]} { > > =C2=A0=C2=A0=C2=A0=C2=A0 return > > =C2=A0} > >=20 > > -set timeout 30 > > +with_timeout_factor 3 { > > + > > =C2=A0gdb_test_no_output "set max-completions unlimited" > >=20 > > =C2=A0gdb_test_no_output "complete print values\[0\].x." \ > > @@ -995,3 +996,6 @@ foreach_with_prefix spc { " " "" } { > > =C2=A0=09=C2=A0=C2=A0=C2=A0 } > > =C2=A0=C2=A0=C2=A0=C2=A0 } > > =C2=A0} > > + > > +# end of with_timeout_factor > > +} > > diff --git a/gdb/testsuite/gdb.base/funcargs.exp b/gdb/testsuite/gdb.ba= se/funcargs.exp > > index fdfdf07b78c..dd3240ba5e0 100644 > > --- a/gdb/testsuite/gdb.base/funcargs.exp > > +++ b/gdb/testsuite/gdb.base/funcargs.exp > > @@ -1031,13 +1031,15 @@ proc_with_prefix stepping_over_trampolines { } = { > > =C2=A0=C2=A0=C2=A0=C2=A0 } > > =C2=A0} > >=20 > > -set prev_timeout $timeout > > + > > =C2=A0if {[istarget "mips*tx39-*"]} { > > -=C2=A0=C2=A0=C2=A0 set timeout 300 > > +=C2=A0=C2=A0=C2=A0 set timeout_factor 30 > > =C2=A0} else { > > -=C2=A0=C2=A0=C2=A0 set timeout 60 > > +=C2=A0=C2=A0=C2=A0 set timeout_factor 6 > > =C2=A0} >=20 > I would suggest getting rid of this special "mips*tx39-*" case. >=20 > LGTM with those fixed. >=20 > Approved-By: Simon Marchi >=20 > Simon