From: "Michal Suchánek" <msuchanek@suse.de>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: "AKASHI Takahiro" <takahiro.akashi@linaro.org>,
"Heiko Thiery" <heiko.thiery@gmail.com>,
"Marek Behún" <kabel@kernel.org>, "Pali Rohár" <pali@kernel.org>,
"Quentin Schulz" <quentin.schulz@theobroma-systems.com>,
"Samuel Holland" <samuel@sholland.org>,
"Simon Glass" <sjg@chromium.org>, "Stefan Roese" <sr@denx.de>,
"Weijie Gao" <weijie.gao@mediatek.com>,
u-boot@lists.denx.de
Subject: Re: [PATCH] tests: Build correct sandbox configuration on 32bit
Date: Fri, 14 Oct 2022 10:43:31 +0200 [thread overview]
Message-ID: <20221014084331.GI28810@kitsune.suse.cz> (raw)
In-Reply-To: <1e2f9172-10a5-e471-0e0b-7aa14905de2c@gmx.de>
On Fri, Oct 14, 2022 at 05:05:26AM +0200, Heinrich Schuchardt wrote:
> On 10/13/22 22:28, Michal Suchanek wrote:
> > Currently sandbox configuration defautls to 64bit and there is no
> > automation for building 32bit sandbox on 32bit hosts.
> >
> > cpp does not know about target specification, code needs to be compiled
> > to determine integer width.
> >
> > Add a test program that prints the integer width, and a make target that
> > aligns the sandbox configuration with the result.
> >
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> >
> > Makefile | 6 ++++++
> > doc/arch/sandbox.rst | 16 +++++++++++-----
> > test/py/conftest.py | 1 +
> > tools/Makefile | 2 ++
> > tools/bits-per-long.c | 14 ++++++++++++++
> > 5 files changed, 34 insertions(+), 5 deletions(-)
> > create mode 100644 tools/bits-per-long.c
> >
> > diff --git a/Makefile b/Makefile
> > index 3866cc62f9..e5463573f3 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2166,6 +2166,12 @@ tools-all: envtools tools ;
> > cross_tools: export CROSS_BUILD_TOOLS=y
> > cross_tools: tools ;
> >
> > +PHONY += set_host_bits
> > +set_host_bits: tools
> > + $(Q)sed -i -e /CONFIG_HOST_$$($(objtree)/tools/bits-per-long)BIT/d $(KCONFIG_CONFIG)
> > + $(Q)sed -i -E -e "s/CONFIG_HOST_(..)BIT=y/# CONFIG_HOST_\1BIT is not set/" $(KCONFIG_CONFIG)
> > + $(Q)echo CONFIG_HOST_$$($(objtree)/tools/bits-per-long)BIT=y >> $(KCONFIG_CONFIG)
> > +
> > .PHONY : CHANGELOG
> > CHANGELOG:
> > git log --no-merges U-Boot-1_1_5.. | \
> > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
> > index 068d4a3be4..d751205eba 100644
> > --- a/doc/arch/sandbox.rst
> > +++ b/doc/arch/sandbox.rst
> > @@ -33,9 +33,11 @@ machines.
> >
> > There are two versions of the sandbox: One using 32-bit-wide integers, and one
> > using 64-bit-wide integers. The 32-bit version can be build and run on either
> > -32 or 64-bit hosts by either selecting or deselecting CONFIG_SANDBOX_32BIT; by
> > -default, the sandbox it built for a 32-bit host. The sandbox using 64-bit-wide
> > -integers can only be built on 64-bit hosts.
> > +32 or 64-bit hosts by either selecting or deselecting HOST_64BIT; by
> > +default, the sandbox it built for a 64-bit host. The sandbox using 64-bit-wide
> > +integers can only be built on 64-bit hosts. There is no automation for ensuring
> > +32bit build on 32bit hosts - use ``make set_host_bits`` to adjust the sandbox
> > +config.
> >
> > Note that standalone/API support is not available at present.
> >
> > @@ -51,7 +53,9 @@ Basic Operation
> >
> > To run sandbox U-Boot use something like::
> >
> > - make sandbox_defconfig all
> > + make sandbox_defconfig
> > + make set_host_bits
> > + make all
>
> Thanks for addressing the problem of sandbox bitness.
>
> We should not make building the sandbox more complicated. You could
> integrate building set_host_bits into an existing target like u-boot.cfg:.
>
> Overall an approach with an external program is too complicated.
> CONFIG_HOST_32BIT and CONFIG_HOST_64BIT are used to define
> CONFIG_SANDBOX_BITS_PER_LONG.
And for making SANDBOX64 depend on 64bit build.
>
> We could add
>
> #ifndef __LP64__
> #undef SANDBOX_BITS_PER_LONG
> #define SANDBOX_BITS_PER_LONG 32
> #endif
If we are willing to depend on this define which is clearly named as
compiler-internal we could do similar to cc-option to run something like
$(CC) -dM -E - < /dev/null | grep -q _LP64
>
> to the top of arch/sandbox/include/asm/posix_types.h and use
>
> #if defined(CONFIG_HOST_64BIT) && defined(__LP64__)
>
> in drivers/misc/swap_case.c to solve the problem. This demonstrates that
> CONFIG_HOST_32BIT and CONFIG_HOST_64BIT are superfluous symbols.
Not really.
Thanks
Michal
next prev parent reply other threads:[~2022-10-14 8:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 20:28 [PATCH] tests: Build correct sandbox configuration on 32bit Michal Suchanek
2022-10-14 3:05 ` Heinrich Schuchardt
2022-10-14 8:43 ` Michal Suchánek [this message]
2022-10-15 5:00 ` Heinrich Schuchardt
2022-10-14 15:56 ` Simon Glass
2022-10-14 20:52 ` [PATCH v2] " Michal Suchanek
2022-10-15 4:54 ` Heinrich Schuchardt
2022-10-15 7:19 ` Michal Suchánek
2022-10-15 17:53 ` Simon Glass
2022-10-15 18:31 ` Heinrich Schuchardt
2022-10-15 18:39 ` Simon Glass
2022-10-15 19:05 ` Heinrich Schuchardt
2022-10-15 19:17 ` Michal Suchánek
2022-10-15 19:35 ` Heinrich Schuchardt
2022-10-15 19:24 ` Simon Glass
2022-10-15 19:29 ` Heinrich Schuchardt
2022-10-15 19:46 ` Simon Glass
2022-10-15 20:27 ` Heinrich Schuchardt
2022-10-17 7:28 ` Michal Suchánek
2022-10-19 13:18 ` Simon Glass
2022-10-22 1:05 ` Simon Glass
2022-10-22 19:38 ` Michal Suchánek
2022-10-22 21:22 ` [PATCH] sandbox: Correctly define BITS_PER_LONG Michal Suchanek
2022-10-22 21:52 ` Heinrich Schuchardt
2022-10-23 7:50 ` Michal Suchánek
2022-10-23 7:56 ` Heinrich Schuchardt
2022-10-23 11:30 ` Michal Suchánek
2023-03-01 20:14 ` Simon Glass
2022-10-15 5:05 ` [PATCH] tests: Build correct sandbox configuration on 32bit Heinrich Schuchardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221014084331.GI28810@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=heiko.thiery@gmail.com \
--cc=kabel@kernel.org \
--cc=pali@kernel.org \
--cc=quentin.schulz@theobroma-systems.com \
--cc=samuel@sholland.org \
--cc=sjg@chromium.org \
--cc=sr@denx.de \
--cc=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=weijie.gao@mediatek.com \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox