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?
It's a difference in the presentation of args in BSD. When reviewing the code,
Kyle Evans said:
>> IIRC imgact_binmisc will have the resolved path but preserve argv as
>> it should have been were it not emulated, so we have to re-evaluate
>> the PATH search here because we try to be faithful to the context.
At the time, I confirmed that behavior. Thinking about it, if '.' isn't in the
path, and we can't find it, then we're not in this condition. So that means
looking for it in '.' also won't break anything and will fix this issue. I'll
rework bsd-user's bsdload.c to improve the logic.
Warner