* Stop test-in-container trying to run other-OS binaries
@ 2018-12-04 1:41 Joseph Myers
2018-12-04 5:31 ` DJ Delorie
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2018-12-04 1:41 UTC (permalink / raw)
To: libc-alpha
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 <joseph@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
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop test-in-container trying to run other-OS binaries
2018-12-04 1:41 Stop test-in-container trying to run other-OS binaries Joseph Myers
@ 2018-12-04 5:31 ` DJ Delorie
2018-12-04 9:31 ` Florian Weimer
2018-12-04 12:38 ` Joseph Myers
0 siblings, 2 replies; 6+ messages in thread
From: DJ Delorie @ 2018-12-04 5:31 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers <joseph@codesourcery.com> writes:
> In this case, the x86 architecture means the binary executes, but
> dumps core rather than actually working.
Because cross-compiled, I assume?
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop test-in-container trying to run other-OS binaries
2018-12-04 5:31 ` DJ Delorie
@ 2018-12-04 9:31 ` Florian Weimer
2018-12-04 12:38 ` Joseph Myers
1 sibling, 0 replies; 6+ messages in thread
From: Florian Weimer @ 2018-12-04 9:31 UTC (permalink / raw)
To: DJ Delorie; +Cc: Joseph Myers, libc-alpha
* 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop test-in-container trying to run other-OS binaries
2018-12-04 5:31 ` DJ Delorie
2018-12-04 9:31 ` Florian Weimer
@ 2018-12-04 12:38 ` Joseph Myers
2018-12-04 16:10 ` DJ Delorie
2018-12-04 16:17 ` DJ Delorie
1 sibling, 2 replies; 6+ messages in thread
From: Joseph Myers @ 2018-12-04 12:38 UTC (permalink / raw)
To: DJ Delorie; +Cc: libc-alpha
On Tue, 4 Dec 2018, DJ Delorie wrote:
> Joseph Myers <joseph@codesourcery.com> writes:
> > 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.
> 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
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop test-in-container trying to run other-OS binaries
2018-12-04 12:38 ` Joseph Myers
@ 2018-12-04 16:10 ` DJ Delorie
2018-12-04 16:17 ` DJ Delorie
1 sibling, 0 replies; 6+ messages in thread
From: DJ Delorie @ 2018-12-04 16:10 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers <joseph@codesourcery.com> writes:
>> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop test-in-container trying to run other-OS binaries
2018-12-04 12:38 ` Joseph Myers
2018-12-04 16:10 ` DJ Delorie
@ 2018-12-04 16:17 ` DJ Delorie
1 sibling, 0 replies; 6+ messages in thread
From: DJ Delorie @ 2018-12-04 16:17 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-12-04 16:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-04 1:41 Stop test-in-container trying to run other-OS binaries Joseph Myers
2018-12-04 5:31 ` DJ Delorie
2018-12-04 9:31 ` Florian Weimer
2018-12-04 12:38 ` Joseph Myers
2018-12-04 16:10 ` DJ Delorie
2018-12-04 16:17 ` DJ Delorie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).