From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 0D7B3385842E for ; Mon, 13 Dec 2021 12:55:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D7B3385842E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id B7D8130002FC; Mon, 13 Dec 2021 13:55:16 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 9A65C4001046; Mon, 13 Dec 2021 13:55:15 +0100 (CET) Message-ID: <3dfa1159b9b8aa7bd0015510a9ce7d546e8300e9.camel@klomp.org> Subject: Re: [PATCH] Add valgrind smoke test From: Mark Wielaard To: DJ Delorie Cc: alexandra.khirnova@gmail.com, libc-alpha@sourceware.org, ahajkova@redhat.com Date: Mon, 13 Dec 2021 13:55:15 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 13 Dec 2021 12:55:23 -0000 On Fri, 2021-12-10 at 14:15 -0500, DJ Delorie wrote: > Mark Wielaard writes: > > > I.e. (in short): > > >=20 > > > ${...} /bin/sh valgrind foo <- runs /bin/sh with new glibc > > > /bin/sh ${...} valgrind foo <- runs valgrind with new glibc > > > /bin/sh valgrind ${...} foo <- runs foo with new glibc > >=20 > > The intent is to test the valgrind available in the test environment > > against the just-built glibc (that is both valgrind and the test binary > > valgrind-test, which are really the same process) >=20 > More like a mix: >=20 > /bin/sh ${...} valgrind ${...} foo >=20 > The ${...} is all the variables needed to run in the just-built > environment, so ${test_wrapper_env} ${run_program_env} $rtld > --library-path "$library_path" >=20 > You need to include all that muck for each binary you want to run in the > just-built environment; it's not inherited. >=20 > Although you likely don't want the test_wrapper_env for the "foo" as it > might include a nested ssh, it's complicated and requires a bit of trial > and error. You definitely need the rest else the test program will use > the target's system libc. OK. So we would like to invoke the shell /bin/sh as is, so that is just the system shell? Then we want to use that to invoke valgrind in the test environment (with or without the new ld.so which doesn't really matter because...) we then invoke valgrind on the newly build ld.so with the new library_path, which then invokes our test binary. One question is why /bin/sh itself doesn't need to run inside/using the test environment. Doesn't it make things easier if the /bin/sh itself is executing inside the test environment or does that complicate things? But either way should work, although running valgrind on ld.so directly isn't really supported on some arches (e.g. ppc64 because of some odd relocation issues). But if we can figure out what the system ld.so is then we can use that in the first invocation to see if it works and SKIP, exit 77 when it doesn't. What is the correct way to extract the system ld.so? So the tst-valgrind-smoke.sh would have the test whether valgrind is available as is. Then an extra test to see if valgrind running on the system ld.so actually works in the test environment. And finally the actual test using the new ld.so and test library path. # Test valgrind is available in the test environment ${test_wrapper_env} ${run_program_env} \ $rtld --library-path "$library_path" \ /bin/sh -c 'command -v valgrind' || exit 77 # Test valgrind works with the system ld.so in the test environment # XXX how to get/set ${system_rtld}??? /bin/sh -c \ "${test_wrapper_env} ${run_program_env} \ valgrind -q --error-exitcode=3D1 \ ${system_rtld} ${test_prog}" || exit 77 # Run the actual test under valgrind and the new ld.so /bin/sh -c \ "${test_wrapper_env} ${run_program_env} \ valgrind -q --error-exitcode=3D1 \ ${rtld} --library-path ${library_path} ${test_prog}" > > > (in general, testing in a cross-compiled case is an excellent way to > > > see if you got the rtld stuff in the right place ;-) > >=20 > > I never did a cross-compiled case. Is there a description of that > > process? >=20 > You can use build-many-glibcs to do a cross build but I don't know if > that supports running the testsuite fully. Do you have an example how to invoke this script? It starts with "This script takes as arguments a directory name (containing a src subdirectory with sources of the relevant toolchain components)". What are the relevant toolchain components? > Typically you'd have a remote machine you can ssh to, which nfs mounts > your build to the same path, then set a variable to wrap all the tests > in a script that ssh's. >=20 > https://sourceware.org/glibc/wiki/Testing/Testsuite#Testing_with_a_cross-= compiler >=20 > Look at glibc's scripts/cross-test-ssh.sh for instructions OK, so we need multiple machines that can nfs mount each others source and/or build dirs. Is there a setup like that in the gcc compile farm? Thanks, Mark