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 241E63858D20 for ; Wed, 13 Sep 2023 14:34:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 241E63858D20 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 38DEYG1c015203 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2023 10:34:21 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 38DEYG1c015203 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1694615661; bh=64N9vs8ZxISR8qm8g8I3HoQaZlJGJruWcQor0EPLLys=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GoxrANNSXGpOrkcos0jkDEp7HUPb9wkknXrxuwj5qqqqt54/Q20PaNzDoN/TYgpeK SYIloZksHkI99ICKXzYaxGt4ArIw+hY6EvEAuWimxYoGNnA6iq3V68MIUvmOcnt96O YNP1l++gQP2SMAUX/nMiseckZIY1frgosg7qzTzo= 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 8A4341E028; Wed, 13 Sep 2023 10:34:16 -0400 (EDT) Message-ID: Date: Wed, 13 Sep 2023 10:34:16 -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: <20230913101815.178154-17-luis.machado@arm.com> 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 14:34:16 +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: On 9/13/23 06:18, Luis Machado wrote: > v3: > > - Additional documentation for some testcases based on upstream reviews. > - Addressed upstream review comments. > > v2: > - Introduced a couple helper functions to determine the available SVE and SME > vector lengths. > > - Before running a batch of tests, validate that the target supports a certain > SVE vector length or SME streaming vector length. If not supported, skip > that batch of tests. > > - Fixed up native core file testing to remove generation of a spurious core > file, which later would be reported as unexpected by the testsuite. > > - Fixed tpidr2 dump in core file tests. > -- > > Add 5 SVE/SME tests to exercise all the new features like reading/writing > registers, pseudo-registers, signal frames and core files. > > - Sanity check for SME: Gives a brief smoke test to make sure the most basic > of features are working correctly. > > - ZA unavailability tests: Validates the behavior/content of the ZA register > is correct when no payload is available. It also exercises changing the > vector lengths. > > - ZA Availability tests: These tests exercise reading/writing to all the > possible ZA pseudo-registers, and validates the state is correct. > > - Core file tests: Validates that core file reading and writing works > correctly and that all state dumped/loaded is sane. This is exercised for > both Linux Kernel core files and gcore core files. > > - Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD > values across signal frames. > > Since some of these tests are very lengthy and take a little while to run > (under QEMU at the moment), I decided to parallelize them into smaller > chunks so we can throw some more CPU power at them so they run faster. > > I'd still like to add a few more tests to give the testsuite more coverage > in the areas of SME/SVE. Hopefully in the near future that will happen. > > Just a reminder that most of these tests will FAIL when running against > gdbserver because all of the tests change the vector length mid-execution > in some way. Since gdbserver can't communicate the change of state over > RSP to GDB, we will always get wrong state from gdbserver. Is it possible to determine the circumstances when they will fail and kfail them? It's not good practice to add known failing tests. I just skimmed the code, but since some of it is deep AArch64-specific stuff, I can't review it properly without spending days on it. But overall it seems well structured and well commented. Simon