From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A84C73858D20 for ; Wed, 13 Sep 2023 15:26:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A84C73858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 38DFQcxg000486 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2023 11:26:42 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 38DFQcxg000486 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1694618803; bh=AFbD7I2A47LC/YOmETtxu2wex4fkyuDxgoDl2dGoV3c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ajHU+yEIeoQKa012LdQq7MZI91ewydJzGM4jofcPsmme5hZSp03zm4CADm/ER2iRk EMC4/RMVS+e3vPuRCN70IFrnQgD0EGeo2su7+BAJWKwOvR6R9HPBxeDLGAfHYubumm 05cJT+ok9gU1oD329NfUph/iT66LrQXaHoLFa+Jc= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BD8601E028; Wed, 13 Sep 2023 11:26:37 -0400 (EDT) Message-ID: <3e6e2fe6-e671-4106-b243-0446450731ba@polymtl.ca> Date: Wed, 13 Sep 2023 11:26:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 16/17] [gdb/testsuite] sme: Add SVE/SME testcases Content-Language: fr To: Luis Machado , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230913101815.178154-1-luis.machado@arm.com> <20230913101815.178154-17-luis.machado@arm.com> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 13 Sep 2023 15:26:38 +0000 X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >> Is it possible to determine the circumstances when they will fail and >> kfail them? It's not good practice to add known failing tests. > > Yes, as long as we can determine that gdb is talking to a remote target, we can then > assume we will have a lot of failures. Those should technically go away whenever we > fix the communication of changes to the vector length over RSP (Thiago was looking at > it). > > I seem to recall there was a bit of an unfortunate situation when trying to tell if we > were talking to a debugging stub in extended gdbserver remote mode. Is that still the case? > > Otherwise this should be fairly simple to address. And it may be a better idea to just bail out > as opposed to trying to run the tests that are known to fail. When the RSP situation is solved, > we can lift this restriction along with it. Thoughts? I think that kfailing them is fine, but it is sometimes tricky. If you setup_kfail to tell the testsuite the next test is going to fail, but the test actually passes, the testsuite will issue a KPASS, which is actually treated as some failure. I'd try the kfail approach first, but if it is too problematic then bailing out early would be ok too. These procs could help you get started, but feel free to add more if needed: - gdb_is_target_remote - target_is_gdbserver Simon