qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 3/3] tests/tcg: commit Makefile atrocities in the name of


From: Alex Bennée
Subject: Re: [RFC PATCH 3/3] tests/tcg: commit Makefile atrocities in the name of portability
Date: Fri, 17 Sep 2021 17:41:16 +0100
User-agent: mu4e 1.7.0; emacs 28.0.50

Warner Losh <imp@bsdimp.com> writes:

> On Fri, Sep 17, 2021 at 8:39 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  Warner Losh <imp@bsdimp.com> writes:
>
>  > On Tue, Aug 3, 2021 at 5:02 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>  >
>  >  Not all of the multiarch tests are pure POSIX so elide over those
>  >  tests on a non-Linux system. This allows for at least some of the
>  >  tests to be nominally usable by *BSD user builds.
>  >
>  >  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>  >  Cc: Warner Losh <imp@bsdimp.com>
>  >  ---
>  >   tests/tcg/multiarch/Makefile.target | 6 +++++-
>  >   tests/tcg/x86_64/Makefile.target    | 4 ++++
>  >   2 files changed, 9 insertions(+), 1 deletion(-)
>  >
>  > Acked-by: Warner Losh <imp@bsdimp.com>
>  >
>  > To do this with gcc10, however, I had to add -Wno-error=overflow
>  > otherwise I got a lot of warnings about constants being truncated to
>  > 0.
>  >
>  > It also fails the sha1 test, but when I run it by hand it works. It turns
>  > out that I have a sha1 in my path, and at least in the bsd-user edition
>  > of qemu-i386 tries to run that and fails.
>  >
>  > Also, the hello world program needed tweaking
>  >
>  > So with this applied and the following patch
>  >
>  > diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
>  > index 63cf1b2573..39420631a8 100644
>  > --- a/tests/tcg/Makefile.target
>  > +++ b/tests/tcg/Makefile.target
>  > @@ -155,7 +155,7 @@ RUN_TESTS+=$(EXTRA_RUNS)
>  >
>  >  ifdef CONFIG_USER_ONLY
>  >  run-%: %
>  > -       $(call run-test, $<, $(QEMU) $(QEMU_OPTS) $<, "$< on 
> $(TARGET_NAME)")
>  > +       $(call run-test, $<, $(QEMU) $(QEMU_OPTS) ./$<, "$< on 
> $(TARGET_NAME)")
>  >
>  >  run-plugin-%:
>  >         $(call run-test, $@, $(QEMU) $(QEMU_OPTS) \
>  > @@ -168,7 +168,7 @@ run-%: %
>  >         $(call run-test, $<, \
>  >           $(QEMU) -monitor none -display none \
>  >                   -chardev file$(COMMA)path=$<.out$(COMMA)id=output \
>  > -                 $(QEMU_OPTS) $<, \
>  > +                 $(QEMU_OPTS) ./$<, \
>  >           "$< on $(TARGET_NAME)")
>
>  That's weird. I'm not super keen to merge this because it's incomplete
>  (we have a large number of manual run-FOO stanzas). AFAICT neither of
>  the loaders attempt to enumerate and search path so I wonder if this is
>  a function of the shell?
>
> bsd-user does, in fact, search the path. It does so in loader_exec. It does 
> this,
> I believe, to support execing native binaries, but I'll need to check
> on that.

It's certainly different from what linux-user does. The execing of
native binaries seems a bit niche given you can always pass an explicit
path. Maybe you could tweak loader_exec to check for the local binary
first. It seems to skip straight to searching the path if there are no
/'s in the filename.

This is unrelated to how you handle foreign binaries on the BSDs? Is
there an equivalent to binfmt_misc?

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]