From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 719C138930D0 for ; Mon, 24 May 2021 19:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 719C138930D0 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: ekTwU2jRPotF+v4Xh4WzsCnbqCPdt3joHlSzZv01D6cOP+EDa1d0uX17LDfYo5lv9lxuw4n3Q/ RkTdxQLXatJbDeDAMUItQFmkQXTWmIzAeTstbyhLLHMZbNggP13K7czl2XpI2joAZ3q0j+rTuf mz/X/V6vwNe/2GiLbHV+0FibVG9GI2CWhUxt69/pYTnmIOH2HkFW4zltwmvKm42twW+j1uKmBA ZNp5BgjFG5TZjnEzTaff3IZJBNpq4PKPD4BM9Aej8Nb1OfG2EgMOxAA+oa+BgjjbEyLRn3ZXsp cYg= X-IronPort-AV: E=Sophos;i="5.82,325,1613462400"; d="scan'208";a="61569578" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 24 May 2021 11:28:26 -0800 IronPort-SDR: HH1a4dNXMW4CF+0h3g9snG8b/zhEh+G4d3b5EUqvAKOKx3VlTB9pFiEdk47TbtqvJuqtP8yQ/R 0pjdmTgi37SCVFLPKMF1X6iiBQ3B/TbuzLRf7p0AwQuUqwp/+5Rj3geubZwMMwm2t4BbPlQsrU ItTTDsNhsGanFENWM0bO/0oH/SxHz/L0lgZ5uc0tzrfd4FJ836Fq9LMY+ejIpDAPyiqu4/VuXQ hSnFUy6WFYHm/Yh+ZjBZyGP0+95CmPFZ7sKT1UChoETs971EsnSf3hS9NmVnSmNvTa3toFy2j/ U0s= Date: Mon, 24 May 2021 19:28:20 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Carlos O'Donell CC: =?ISO-8859-15?Q?Alexandra_H=E1jkov=E1?= , , =?ISO-8859-15?Q?Alexandra_H=E1jkov=E1?= Subject: Re: [PATCH] Add valgrind smoke test In-Reply-To: Message-ID: References: <20210524121532.1374966-1-ahajkova@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3121.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 19:28:29 -0000 On Mon, 24 May 2021, Carlos O'Donell via Libc-alpha wrote: > > +# Run smoke tests with valgrind to verify dynamic loader > > +ifneq ($(VALGRIND),false) > > +tests-special += $(objpfx)valgrind-smoke-test.out > > +$(objpfx)valgrind-smoke-test.out: $(objpfx)ld.so > > + $(common-objpfx)testrun.sh --tool=valgrind-test /usr/bin/true > $@ > > + $(common-objpfx)testrun.sh --tool=valgrind-test /usr/bin/true --help >> $@ > > +endif > Does this work for cross-compiling? > > Do you correctly detect the target valgrind and does the test wrapper > allow the correct execution of valgrind on the target system? My expectation is that -valgrind won't exist - but AC_CHECK_TOOL is documented as falling back to the tool without a host prefix if a prefixed version doesn't exist, which is a problem. Logically, this test should run if valgrind is available on the test system (which would need to be determined when the tests are run, test-wrapper isn't available when glibc is built), but the test-wrapper interface doesn't strictly support running arbitrary installed programs like that. So you might need a test program (run on the test system via test-wrapper) that itself checks for valgrind being available in the PATH and runs it or returns UNSUPPORTED if not available. That is, something like nptl/tst-pthread-gdb-attach.c, which handles checking for whether gdb is available. There are problems even in native-like cases when no test wrapper is being used. What if glibc is being built and tested for 32-bit x86 but /usr/bin/true is a 64-bit binary? A native build doesn't mean that any particular installed program uses the same ABI as the glibc being built. It's not safe to run /usr/bin/true with the newly built glibc at all (and some systems have /bin/true instead of /usr/bin/true). (That issue could presumably be addressed by building a test program against the newly built glibc and running that in place of /usr/bin/true. So you end up needing to build two test programs against the new glibc, one to check for valgrind and run it if available, and the other to run under valgrind.) -- Joseph S. Myers joseph@codesourcery.com