Re: [PATCH] Add valgrind smoke test

[Mark Wielaard <mark@klomp.org>]

On Fri, 2021-12-10 at 14:15 -0500, DJ Delorie wrote:
> Mark Wielaard <mark@klomp.org> writes:
> > > I.e. (in short):
> > > 
> > > ${...} /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
> > 
> > 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)
> 
> More like a mix:
> 
> /bin/sh ${...} valgrind ${...} foo
> 
> 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"
> 
> You need to include all that muck for each binary you want to run in the
> just-built environment; it's not inherited.
> 
> 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=1 \
   ${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=1 \
   ${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 ;-)
> > 
> > I never did a cross-compiled case. Is there a description of that
> > process?
> 
> 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.
> 
> https://sourceware.org/glibc/wiki/Testing/Testsuite#Testing_with_a_cross-compiler
> 
> 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