From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF14DC433F5 for ; Fri, 17 Sep 2021 17:25:29 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4683360F4A for ; Fri, 17 Sep 2021 17:25:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4683360F4A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bsdimp.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:54170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRHc8-0006Ig-9i for qemu-devel@archiver.kernel.org; Fri, 17 Sep 2021 13:25:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRHaP-0004g3-T9 for qemu-devel@nongnu.org; Fri, 17 Sep 2021 13:23:41 -0400 Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]:38799) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRHaN-0003JY-9H for qemu-devel@nongnu.org; Fri, 17 Sep 2021 13:23:41 -0400 Received: by mail-vs1-xe31.google.com with SMTP id a25so10141260vso.5 for ; Fri, 17 Sep 2021 10:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mZWZtVomlJ/D1OHvcVytPSRJwHNawGbk7vuiHVvbx6Q=; b=gVDKONdlGyh6zpwh8acGnlHs49g81IyGRo0xMx3p9ZbWrkfH8vD3zPEloXhN4c52eI 0D0ulo1047bnnaPPF6uMvr9BriezOaUt2Bqsl2ytYFj0XUFE46emrDryWdtgxZUnj3b6 zyk6Yb8reW7A3GfxF8RCjrJCPBI3sq4u9AnwP0IBJONVoRBsi8geGXqncRePWBdnXjia TnwJC3V3ss1bFSfk+4YzxULtEob9ZKu2khpTQyiAJoARMPOWGMD6zfmutj8Qwwl9eUn/ yKkgomxAtNmGjmAjkSOJ8UbnBxCrUn9+RiAKPHP/BIcxVVlS1YqlRhmEog1mxmqdsKzQ oViQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mZWZtVomlJ/D1OHvcVytPSRJwHNawGbk7vuiHVvbx6Q=; b=ZdPu0cX0iDxz4bB5qGlSm6SCDBb4UgHOEmUOg+wMIom34ImTKprKKUKIX4tGKLWuPz vab/n9wVasmEXQofhdC/bt3aGT0YPEA8HRYsV906RPqea2CApkMrrWQ+uUrsmzujOYCb v8HgoQbXVd3oxWV1z669R9znaCwAsrkQT53WH2JqjUJlMLHz0TYlLaMImC3/pHUiNnvB X42LToEGo55fBgaaONq17bCkQmX4Bd7rx1rlzusnQG/wwrH/4cyAjWq621ftmvfKV+Pg o8J2AuNpYhxaRGpyXp0ddk9dZWXF4detUboYAnTqV+urVbyHerdwQDOy+ZXUxmSwNrmH KtuQ== X-Gm-Message-State: AOAM531irEmGJHenyyL+lMg9kJWKAQA5k0DLHFs96vX9JAxFNBrH0vNP s7gDUyyTFjcqiZyBCpUHnXgFIMDvcqd+xGzZUjWuEw== X-Google-Smtp-Source: ABdhPJwaUHW+JDUmU69/t0nrUGYT2WmwTDCw5jB7OmgVx/+JT1ShE6zqjypAX3PEkct1rwEe3Nq1d2Upo0beFWvHU8w= X-Received: by 2002:a05:6102:cd3:: with SMTP id g19mr9366510vst.12.1631899413746; Fri, 17 Sep 2021 10:23:33 -0700 (PDT) MIME-Version: 1.0 References: <20210803110237.1051032-1-alex.bennee@linaro.org> <20210803110237.1051032-4-alex.bennee@linaro.org> <8735q3tgfo.fsf@linaro.org> <87y27vrw17.fsf@linaro.org> In-Reply-To: <87y27vrw17.fsf@linaro.org> From: Warner Losh Date: Fri, 17 Sep 2021 11:23:22 -0600 Message-ID: Subject: Re: [RFC PATCH 3/3] tests/tcg: commit Makefile atrocities in the name of portability To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Content-Type: multipart/alternative; boundary="000000000000ddc94605cc3430d9" Received-SPF: none client-ip=2607:f8b0:4864:20::e31; envelope-from=wlosh@bsdimp.com; helo=mail-vs1-xe31.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fam@euphon.net, "Daniel P. Berrange" , Eduardo Habkost , Richard Henderson , QEMU Developers , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Stefan Hajnoczi , Cleber Rosa , Paolo Bonzini , Aurelien Jarno Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000ddc94605cc3430d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2021 at 10:45 AM Alex Benn=C3=A9e = wrote: > > Warner Losh writes: > > > On Fri, Sep 17, 2021 at 8:39 AM Alex Benn=C3=A9e > wrote: > > > > Warner Losh writes: > > > > > On Tue, Aug 3, 2021 at 5:02 AM Alex Benn=C3=A9e > 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=C3=A9e > > > Cc: Warner Losh > > > --- > > > tests/tcg/multiarch/Makefile.target | 6 +++++- > > > tests/tcg/x86_64/Makefile.target | 4 ++++ > > > 2 files changed, 9 insertions(+), 1 deletion(-) > > > > > > Acked-by: Warner Losh > > > > > > To do this with gcc10, however, I had to add -Wno-error=3Doverflow > > > 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+=3D$(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=3D$<.out$(COMMA)id=3Dout= put \ > > > - $(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 i= s > > 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 --000000000000ddc94605cc3430d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 17, 2021 at 10:45 AM Alex= Benn=C3=A9e <alex.bennee@lina= ro.org> wrote:

Warner Losh <imp@bsd= imp.com> writes:

> On Fri, Sep 17, 2021 at 8:39 AM Alex Benn=C3=A9e <alex.bennee@linaro.org> w= rote:
>
>=C2=A0 Warner Losh <imp@bsdimp.com> writes:
>
>=C2=A0 > On Tue, Aug 3, 2021 at 5:02 AM Alex Benn=C3=A9e <alex.bennee@linaro.org= > wrote:
>=C2=A0 >
>=C2=A0 >=C2=A0 Not all of the multiarch tests are pure POSIX so elid= e over those
>=C2=A0 >=C2=A0 tests on a non-Linux system. This allows for at least= some of the
>=C2=A0 >=C2=A0 tests to be nominally usable by *BSD user builds.
>=C2=A0 >
>=C2=A0 >=C2=A0 Signed-off-by: Alex Benn=C3=A9e <alex.bennee@linaro.org> >=C2=A0 >=C2=A0 Cc: Warner Losh <imp@bsdimp.com>
>=C2=A0 >=C2=A0 ---
>=C2=A0 >=C2=A0 =C2=A0tests/tcg/multiarch/Makefile.target | 6 +++++-<= br> >=C2=A0 >=C2=A0 =C2=A0tests/tcg/x86_64/Makefile.target=C2=A0 =C2=A0 |= 4 ++++
>=C2=A0 >=C2=A0 =C2=A02 files changed, 9 insertions(+), 1 deletion(-)=
>=C2=A0 >
>=C2=A0 > Acked-by: Warner Losh <imp@bsdimp.com>
>=C2=A0 >
>=C2=A0 > To do this with gcc10, however, I had to add -Wno-error=3Do= verflow
>=C2=A0 > otherwise I got a lot of warnings about constants being tru= ncated to
>=C2=A0 > 0.
>=C2=A0 >
>=C2=A0 > It also fails the sha1 test, but when I run it by hand it w= orks. It turns
>=C2=A0 > out that I have a sha1 in my path, and at least in the bsd-= user edition
>=C2=A0 > of qemu-i386 tries to run that and fails.
>=C2=A0 >
>=C2=A0 > Also, the hello world program needed tweaking
>=C2=A0 >
>=C2=A0 > So with this applied and the following patch
>=C2=A0 >
>=C2=A0 > diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile= .target
>=C2=A0 > index 63cf1b2573..39420631a8 100644
>=C2=A0 > --- a/tests/tcg/Makefile.target
>=C2=A0 > +++ b/tests/tcg/Makefile.target
>=C2=A0 > @@ -155,7 +155,7 @@ RUN_TESTS+=3D$(EXTRA_RUNS)
>=C2=A0 >
>=C2=A0 >=C2=A0 ifdef CONFIG_USER_ONLY
>=C2=A0 >=C2=A0 run-%: %
>=C2=A0 > -=C2=A0 =C2=A0 =C2=A0 =C2=A0$(call run-test, $<, $(QEMU)= $(QEMU_OPTS) $<, "$< on $(TARGET_NAME)")
>=C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0$(call run-test, $<, $(QEMU)= $(QEMU_OPTS) ./$<, "$< on $(TARGET_NAME)")
>=C2=A0 >
>=C2=A0 >=C2=A0 run-plugin-%:
>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$(call run-test, $@, $(QEM= U) $(QEMU_OPTS) \
>=C2=A0 > @@ -168,7 +168,7 @@ run-%: %
>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$(call run-test, $<, \<= br> >=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$(QEMU) -monitor no= ne -display none \
>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-chardev file$(COMMA)path=3D$<.out$(COMMA)id=3Doutput \
>=C2=A0 > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0$(QEMU_OPTS) $<, \
>=C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0$(QEMU_OPTS) ./$<, \
>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"$< on $(TA= RGET_NAME)")
>
>=C2=A0 That's weird. I'm not super keen to merge this because i= t's incomplete
>=C2=A0 (we have a large number of manual run-FOO stanzas). AFAICT neith= er of
>=C2=A0 the loaders attempt to enumerate and search path so I wonder if = this is
>=C2=A0 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 ch= eck
> 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&= #39;s a difference in the presentation of args in BSD. When reviewing the c= ode,
Kyle Evans said:

>> IIRC imgact_bi= nmisc will have the resolved path but preserve argv as
>> it shoul= d 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.
<= div>
At the time, I confirmed that behavior. Thinking about i= t, 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
--000000000000ddc94605cc3430d9--