From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 966E83854155 for ; Fri, 30 Sep 2022 16:13:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 966E83854155 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0037F1474; Fri, 30 Sep 2022 09:13:46 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBE2A3F792; Fri, 30 Sep 2022 09:13:38 -0700 (PDT) From: Richard Sandiford To: Torbjorn SVENSSON Mail-Followup-To: Torbjorn SVENSSON , =?utf-8?Q?Torbj=C3=B6rn?= SVENSSON via Gcc-patches , richard.sandiford@arm.com Cc: =?utf-8?Q?Torbj=C3=B6rn?= SVENSSON via Gcc-patches Subject: Re: [PATCH v2] testsuite: Only run test on target if VMA == LMA References: <20220920132515.844262-1-torbjorn.svensson@foss.st.com> <6b9d664b-e7f4-c7c9-e167-137cfeca5924@foss.st.com> Date: Fri, 30 Sep 2022 17:13:37 +0100 In-Reply-To: <6b9d664b-e7f4-c7c9-e167-137cfeca5924@foss.st.com> (Torbjorn SVENSSON's message of "Fri, 23 Sep 2022 20:37:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-39.0 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sorry for the slow reply. Torbjorn SVENSSON writes: > Hi Richard, > > Thanks for your review. > Comments below. > > On 2022-09-23 19:34, Richard Sandiford wrote: >> Torbj=C3=B6rn SVENSSON via Gcc-patches writes: >>> Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not >>> enough to know if the execution will enter an endless loop, or if it >>> will give a meaningful result. As the execution test only work when >>> VMA and LMA are equal, make sure that this condition is met. >>> >>> 2022-09-16 Torbj=C3=B6rn SVENSSON >>> >>> gcc/testsuite/ChangeLog: >>> >>> * lib/target-supports.exp (check_effective_target_vma_equals_lma): New. >>> * c-c++-common/torture/attr-noinit-1.c: Requre VMA =3D=3D LMA = to run. >>> * c-c++-common/torture/attr-noinit-2.c: Likewise. >>> * c-c++-common/torture/attr-noinit-3.c: Likewise. >>> * c-c++-common/torture/attr-persistent-1.c: Likewise. >>> * c-c++-common/torture/attr-persistent-3.c: Likewise. >>=20 >> Looks like a nice thing to have. >>=20 >> Could you add an entry to doc/sourcebuild.texi too? > > I've added a note and will be shared in a v3. > >>> + >>> + # Example output of objdump: >>> + #vma_equals_lma9059.exe: file format elf32-littlearm >>> + # >>> + #Sections: >>> + #Idx Name Size VMA LMA File off = Algn >>> + # 6 .data 00000558 20000000 08002658 00020000 = 2**3 >>> + # CONTENTS, ALLOC, LOAD, DATA >>> + >>> + # Capture LMA and VMA columns for .data section >>> + if ![ regexp "\d*\d+\s+\.data\s+\d+\s+(\d+)\s+(\d+)" $outp= ut dummy vma lma ] { >>=20 >> Maybe my Tcl is getting rusty, but I'm surprised this quoting works. >> I'd have expected single backslashes to be interpreted as C-style >> sequences (for \n etc) and so be eaten before regexp sees them. >> Quoting with {...} instead of "..." would avoid that. > > Good catch! I'm not fluent in Tcl and apparently, I was not testing this= =20 > well enough before sending it to the list. I got the expected result for= =20 > the test cases, but for the wrong reason. I've correct it for the v3. > >>> + verbose "Could not parse objdump output" 2 >>> + return 0 >>> + } else { >>> + return [string equal $vma $lma] >>> + } >>> + } else { >>> + remote_file build delete $exe >>> + verbose "Could not determine if VMA is equal to LMA. Assum= ing not equal." 2 >>> + return 0 >>> + } >>=20 >> Would it be more conservative to return 1 on failure rather than 0? >> That way, a faulty test would trigger XFAILs rather than UNSUPPORTEDs, >> with XFAILs being more likely to get attention. > > The main issue here is that for targets where VMA !=3D LMA, executing the= =20 > tests will fall into an endless recursion loop. Well, "endless" in the=20 > sense that the stack might be depleted or the test will simply timeout.=20 > The test cases are designed to assume that it's safe to call _start()=20 > from within main() to verify that the state of some variables tagged=20 > with certain attributes are correct after a "reset". Ah, OK. In that case, I agree return 0 is the right choice. >> On the other hand, I suppose we don't lose much if these tests are >> run on common targets only. So either way is OK, just asking. ;-) > > Do you think it's worth to have these tests reach the timeout to have=20 > them in the XFAIL list rather than in the UNSUPPORTED list? > Keep in mind that it's not just one test case, it's 5 test cases times=20 > the number of permutations of the CFLAGS... > It's also not expected that these test cases will be changed in a way=20 > that will make them work when VMA !=3D LMA. Yeah, good points. Let's stick with it as it is then. Thanks, Richard