This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Chroot testsuite


On Sat, Jan 11, 2014 at 6:40 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sat, 11 Jan 2014, Ryan Arnold wrote:
>
>> > glibc testing should not assume any particular packages on the host; it
>> > should work even if what you get from ssh is just a busybox shell (with no
>> > privileges to run chroot).
>>
>> So for the general case of builddir tests being turned into
>> host/install tests (i.e., not integration tests), this means that
>> glibc would copy the local install_root contents onto the remote
>> machine where the tests will then be executed there by invoking the
>> test via the dynamic linker <install_root>/elf/ld[64].so <testcase>?
>
> Yes.  (Well, copying should be optional - it's not needed when you have a
> shared filesystem, but Brooks has requested support for testing without
> such a shared filesystem, which certainly makes sense as well.)

For remote host tests, a post-install-hook specified as an environment
variable would give all the power that's needed.  If the hook isn't
present, then make install will work as it does now, with or without
install_root being present.  If it is present then the
post_install_hook can be called after each local install step.  A
canned hook could live in scripts/.

I suppose a post-make-hook could do something similar for the builddir
if someone wants to pursue that.

Running remote host tests would require a host-test-wrapper= that
copies each testcase to a staging directory, and executes it there.
This wrapper would be similar to the existing test-wrapper= which is
used when remotely executing builddir tests except that
cross-test-ssh.sh doesn't need to copy the testcase to the remote
machine (yet?) since it currently expects a shared filesystem.

If host-test-wrapper isn't present and host tests are run, then the
system just assumes they're to be installed into an
install_root/host_tests staging directory and invoked there indirectly
through the install_root/<path_to_lib>/ld.so.  This requires that make
host_check take an install_root option.

If install_root isn't present in this case, what's the default
behavior?  I suppose the host tests are installed into some staging
directory and then executed, as dynamically linked, against the system
libraries.  Is that useful?

In both cases it'd be useful if make host_check would output the test
invocations with a path relative install_root variable so that the
same tests could be executed from within a chroot later by simply
running the output and leaving install_root unset.
>
>> > It should also not require that any OS
>> > binaries are available that are compatible with the newly built glibc
>> > rather than being linked with some other incompatible libc (consider, for
>> > example, testing an x32 glibc when nothing other than the kernel supports
>> > x32, or testing an ABI-changed glibc as part of bringing up a port).
>>
>> Is this scenario always remote because it means we're testing in a VM
>> or can the kernel now support executing more than one ABI?
>
> It can be native.  The kernel has supported multiple ABIs for many years -
> I expect that most tests done for x86 glibc now are actually done on a
> 64-bit kernel, and the system might or might not have installed any 32-bit
> compatibility library packages the distribution provides.

Oh of course, I was thinking more along the lines of incompatible ABIs.

> So a chroot constructed with a mixture of newly built
> soft-float libraries, and previously built hard-float binaries from the
> distribution, isn't going to work - any binaries needed for the chroot
> tests, beyond those coming with glibc, would have to be built for the
> specific ABI under test.

A chroot that's not ABI compliant with the binaries being run in it
doesn't make any sense anyway.  But yes, a one-size fits all chroot
isn't going to work..  Building the chroots themselves isn't trivial
considering the possibilities.

>
>> > I would not be adverse to the normal glibc testsuite moving to installing
>> > files in a staging directory within the build tree using install_root,
>> > then running tests the same way they would be run with a previously built
>> > and installed glibc, provided this does not require any extra software or
>> > privileges for chroot.
>>
>> I think we've sorted out that this is possible to do this for existing
>> tests that aren't meant to be integration tests that presume they're
>> executing in the specified prefix.
>
> Note however there might still be concerns about how different ways of
> testing exercise different code paths - see the discussion from when
> --enable-hardcoded-path-in-tests was added, that resulted in it being a
> non-default configure option rather than the only way to run tests.  (An
> actual chroot would of course test paths through the dynamic linker that
> are closer to how people normally use glibc than either of the existing
> approaches, or GLIBC_SYSROOT, is.)

So are these integration tests that are maintained outside of glibc,
or glibc tests that presumes an ABI compatible chroot is setup
(somewhere--native or remote)?

>> > I've previously suggested a GLIBC_SYSROOT environment variable for use in
>> > testing, that would allow more of the effects of chroot to be emulated
>> > without needing any privileges or extra installed software, but there were
>> > some concerns about having such a variable.
>>
>> This would be a way around tests that presume they're executing in the
>> specified prefix (such as ldconfig).  This would also solve other
>> problems... such as Linux distributions that want to have experimental
>> toolchains that don't have to have their binaries executed in chroots.
>
> The generic problem of users running programs with a special version of
> glibc not installed in the root directory, and without files from the root
> directory getting used implicitly by glibc, is certainly a motivation for
> GLIBC_SYSROOT beyond the possible use in the glibc testsuite.

Even for ldconfig which is mentioned below, there's the default path
and then there's the location overrides which need to be tested.

Do you recall what the concerns with providing GLIBC_SYSROOT were?  I
imagine the ease of bug reproducibility goes down for OS distributors
because they'll have to have additional verification that
GLIBC_SYSROOT is correctly set.

So if we do add a GLIBC_SYSROOT option.. how does this change host and
builddir testing?

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]