public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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