Discussion:
Stop test-in-container trying to run other-OS binaries
(too old to reply)
Joseph Myers
2018-12-04 01:38:56 UTC
Permalink
I noticed that, now that build-many-glibcs.py no longer copies glibc
sources, I was getting core dumps in my glibc source directories. The
cause appears to be, from the i686-gnu build:

# Copy these DSOs first so we can overwrite them with our own.
for dso in ` env LD_TRACE_LOADED_OBJECTS=1 \
/scratch/jmyers/glibc-bot/build/glibcs/i686-gnu/glibc/elf/ld.so.1 \
/scratch/jmyers/glibc-bot/build/glibcs/i686-gnu/glibc/testroot.pristine/bin/sh \
[...]
Segmentation fault (core dumped)

In this case, the x86 architecture means the binary executes, but
dumps core rather than actually working.

Anything involving running the newly built glibc should only be done
ifeq ($(run-built-tests),yes). This patch conditions the relevant
part of the testroot setup accordingly.

Tested for x86_64, and with build-many-glibcs.py for i686-gnu.

2018-12-04 Joseph Myers <***@codesourcery.com>

* Makefile ($(objpfx)testroot.pristine/install.stamp): Do not run
dynamic linker unless [$(run-built-tests) = yes].

diff --git a/Makefile b/Makefile
index b4703e48fe..fd73d9bae3 100644
--- a/Makefile
+++ b/Makefile
@@ -374,6 +374,7 @@ $(objpfx)testroot.pristine/install.stamp :
cp $(objpfx)support/shell-container $(objpfx)testroot.pristine/bin/sh
cp $(objpfx)support/echo-container $(objpfx)testroot.pristine/bin/echo
cp $(objpfx)support/true-container $(objpfx)testroot.pristine/bin/true
+ifeq ($(run-built-tests),yes)
# Copy these DSOs first so we can overwrite them with our own.
for dso in `$(test-wrapper-env) LD_TRACE_LOADED_OBJECTS=1 \
$(objpfx)elf/$(rtld-installed-name) \
@@ -393,6 +394,7 @@ $(objpfx)testroot.pristine/install.stamp :
mkdir -p `dirname $(objpfx)testroot.pristine$$dso` ;\
$(test-wrapper) cp $$dso $(objpfx)testroot.pristine$$dso ;\
done
+endif
$(MAKE) install DESTDIR=$(objpfx)testroot.pristine
touch $(objpfx)testroot.pristine/install.stamp
--
Joseph S. Myers
***@codesourcery.com
DJ Delorie
2018-12-04 05:31:01 UTC
Permalink
Post by Joseph Myers
In this case, the x86 architecture means the binary executes, but
dumps core rather than actually working.
Because cross-compiled, I assume?
Post by Joseph Myers
Anything involving running the newly built glibc should only be done
ifeq ($(run-built-tests),yes). This patch conditions the relevant
part of the testroot setup accordingly.
Can $(run-built-tests) ever change from run to run, for the same build?
I mean, it's not dependent on some external environment variables or
ssh-to-target settings?

If it can't change, we don't (shouldn't?) need the testroot *at all*,
because test-container will never run either.
Florian Weimer
2018-12-04 09:31:02 UTC
Permalink
Post by DJ Delorie
Can $(run-built-tests) ever change from run to run, for the same build?
I mean, it's not dependent on some external environment variables or
ssh-to-target settings?
It's a user-customizable knob. It's common to use run-built-tests=no to
build all tests in a subdirectory and then run a few of them manually.

Thanks,
Florian
Joseph Myers
2018-12-04 12:38:20 UTC
Permalink
Post by DJ Delorie
Post by Joseph Myers
In this case, the x86 architecture means the binary executes, but
dumps core rather than actually working.
Because cross-compiled, I assume?
Yes. Whatever Hurd interfaces it attempts to access obviously aren't
available.
Post by DJ Delorie
If it can't change, we don't (shouldn't?) need the testroot *at all*,
because test-container will never run either.
It's not needed - the reasoning for keeping the rest of the creation (that
works fine without needing to be able to run binaries using the new glibc)
was more to minimize the differences between the cross and native testing
cases (so any problems with the rest of the Makefile rules for creating
the testroot would still be detected in cross testing, for example).
--
Joseph S. Myers
***@codesourcery.com
DJ Delorie
2018-12-04 16:10:41 UTC
Permalink
Post by Joseph Myers
Post by DJ Delorie
If it can't change, we don't (shouldn't?) need the testroot *at all*,
because test-container will never run either.
It's not needed - the reasoning for keeping the rest of the creation (that
works fine without needing to be able to run binaries using the new glibc)
was more to minimize the differences between the cross and native testing
cases (so any problems with the rest of the Makefile rules for creating
the testroot would still be detected in cross testing, for example).
My concern is that if we - at any point - create a partial testroot and
later try to use it, we get failures. I'd really rather defer creating
the testroot until the first time test-container actually *runs* but I
can't find a way to do that with our current Makefile setup.

If you want to put this in the "the user needs to do the right thing"
category wrt manually disabling tests sometimes, I'm OK with that.
DJ Delorie
2018-12-04 16:17:01 UTC
Permalink
Post by DJ Delorie
If you want to put this in the "the user needs to do the right thing"
category wrt manually disabling tests sometimes, I'm OK with that.
To be clear, if the user gets to keep both pieces when he/she breaks it,
the original patch is OK with me. It's a delicate bit of
dependency-ness and resorting to simple hacks is probably the best we
can do.

Loading...