[v2,0/7] selftests/nolibc: customize CROSS_COMPILE for all supported architectures

  Hi, Willy

Here is v2 of the customized CROSS_COMPILE support, this helps a lot
during the testing of the other cross-arch nolibc changes:

    $ ARCHS="i386 x86_64 arm64 arm mips ppc ppc64 ppc64le riscv s390"
    $ for arch in ${ARCHS[@]}; do printf "%9s: " $arch; make run-user XARCH=$arch | grep status; done

Based on your suggestion, we did this changes:

- The qemu notes patch [1] is removed, welcome your doc file ;-)
- Arnd's crosstools are customized by default
- Import cc-cross-prefix to support local cross toolchains too
- Use mips64 toolchains for mips like x86_64 toolchains for i386, allow
  download less toolchains
- Use HOSTCC for libc-test compiling

Changes from v1 --> v2:

* selftests/nolibc: allow use x86_64 toolchain for i386

    No change.

* selftests/nolibc: allow use mips64 toolchain for mips

    Allow download less toolchains, save time save storage space

* selftests/nolibc: libc-test: use HOSTCC instead of CC

    libc-test is mainly for local test, use HOSTCC

* selftests/nolibc: allow customize CROSS_COMPILE by architecture

    Moved the ../../../scripts/Makefile.include after our customized
    CROSS_COMPILE, to let it prefix CC with $(CROSS_COMPILE) for us.

* selftests/nolibc: customize CROSS_COMPILE for all architectures

    Use Arnd's crosstools as the default ones

* selftests/nolibc: import cc-cross-prefix macro
  selftests/nolibc: allow use cross toolchains from software repository

    Import cc-cross-prefix to allow customize a list of the cross
    compilers, the ones from local repositories are appended in.

    If already installed ones from local repos, why not use them, let's
    do it.

Willy, since this series is really important to test the coming
patchsets, I send it here before the others to simplify the testing, but
we can delay its review, it is not urgent.

And here [2] is the simple script I wrote to download, decompress and
configure the PATH variable for Anrd's crosstools, hope it helps.

Best regards,
Zhangjin Wu
---
[1]: https://lore.kernel.org/lkml/6de680acbc2d87e13a680d4453ef022568bf489b.1691263493.git.falcon@tinylab.org/
[2]: https://gitee.com/tinylab/linux-lab/blob/next/tools/nolibc/crosstool.sh
 v1: https://lore.kernel.org/lkml/cover.1691263493.git.falcon@tinylab.org/ 

Zhangjin Wu (7):
  selftests/nolibc: allow use x86_64 toolchain for i386
  selftests/nolibc: allow use mips64 toolchain for mips
  selftests/nolibc: libc-test: use HOSTCC instead of CC
  selftests/nolibc: allow customize CROSS_COMPILE by architecture
  selftests/nolibc: customize CROSS_COMPILE for all architectures
  selftests/nolibc: import cc-cross-prefix macro
  selftests/nolibc: allow use cross toolchains from software repository

 tools/testing/selftests/nolibc/Makefile | 38 +++++++++++++++++++++----
 1 file changed, 33 insertions(+), 5 deletions(-)
  

Hi Zhangjin,

On Sat, Aug 12, 2023 at 04:27:01AM +0800, Zhangjin Wu wrote:
> Hi, Willy
> 
> Here is v2 of the customized CROSS_COMPILE support, this helps a lot
> during the testing of the other cross-arch nolibc changes:
> 
>     $ ARCHS="i386 x86_64 arm64 arm mips ppc ppc64 ppc64le riscv s390"
>     $ for arch in ${ARCHS[@]}; do printf "%9s: " $arch; make run-user XARCH=$arch | grep status; done
> 
> Based on your suggestion, we did this changes:
> 
> - The qemu notes patch [1] is removed, welcome your doc file ;-)
> - Arnd's crosstools are customized by default
> - Import cc-cross-prefix to support local cross toolchains too
> - Use mips64 toolchains for mips like x86_64 toolchains for i386, allow
>   download less toolchains
> - Use HOSTCC for libc-test compiling
(...)

I think it's basically OK (just this mips64 thing). I've picked patch 3
already since it's a fix. Once we agree on what to do there, I can queue
it if that helps (I can modify mips64- to mips- in the patch if that's
OK for you, no need to resend for this, just let me know).

I think that later I'll further extend XARCH with new variants to
support ARMv5 and Thumb2, because we have different code for this
and I continue to manually change the CFLAGS to test both.

Thanks,
Willy
  

Hi, Willy

> Hi Zhangjin,
> 
> On Sat, Aug 12, 2023 at 04:27:01AM +0800, Zhangjin Wu wrote:
> > Hi, Willy
> > 
> > Here is v2 of the customized CROSS_COMPILE support, this helps a lot
> > during the testing of the other cross-arch nolibc changes:
> > 
> >     $ ARCHS="i386 x86_64 arm64 arm mips ppc ppc64 ppc64le riscv s390"
> >     $ for arch in ${ARCHS[@]}; do printf "%9s: " $arch; make run-user XARCH=$arch | grep status; done
> > 
> > Based on your suggestion, we did this changes:
> > 
> > - The qemu notes patch [1] is removed, welcome your doc file ;-)
> > - Arnd's crosstools are customized by default
> > - Import cc-cross-prefix to support local cross toolchains too
> > - Use mips64 toolchains for mips like x86_64 toolchains for i386, allow
> >   download less toolchains
> > - Use HOSTCC for libc-test compiling
> (...)
> 
> I think it's basically OK (just this mips64 thing). I've picked patch 3
> already since it's a fix. Once we agree on what to do there, I can queue
> it if that helps (I can modify mips64- to mips- in the patch if that's
> OK for you, no need to resend for this, just let me know).
>

It is ok for me, thanks ;-)

I thought somebody may add mips64 support soon, but we do only have mips
currently, it is fair to not use mips64 toolchain.

> I think that later I'll further extend XARCH with new variants to
> support ARMv5 and Thumb2, because we have different code for this
> and I continue to manually change the CFLAGS to test both.
>

Ok, what about further add x86_64 as the default variant for x86 (like ppc for
powerpc)? and then it is able to only resereve the variables for x86_64. I have
prepared a patch for this goal in our new tinyconfig patchset, it will further
avoid adding the same nolibc-test-x86.config and nolibc-test-x86_64.config.

Best regards,
Zhangjin

> Thanks,
> Willy
  

On Sun, Aug 13, 2023 at 06:05:03PM +0800, Zhangjin Wu wrote:
> > I think that later I'll further extend XARCH with new variants to
> > support ARMv5 and Thumb2, because we have different code for this
> > and I continue to manually change the CFLAGS to test both.
> >
> 
> Ok, what about further add x86_64 as the default variant for x86 (like ppc for
> powerpc)? and then it is able to only resereve the variables for x86_64. I have
> prepared a patch for this goal in our new tinyconfig patchset, it will further
> avoid adding the same nolibc-test-x86.config and nolibc-test-x86_64.config.

I'm confused, x86 already defaults to x86_64, it's just that it depends
on the .config itself to figure whether to produce a 32- or 64-bit kernel.
But for example it starts qemu in 64-bit mode. Am I missing anything ?

Willy
  

> On Sun, Aug 13, 2023 at 06:05:03PM +0800, Zhangjin Wu wrote:
> > > I think that later I'll further extend XARCH with new variants to
> > > support ARMv5 and Thumb2, because we have different code for this
> > > and I continue to manually change the CFLAGS to test both.
> > >
> > 
> > Ok, what about further add x86_64 as the default variant for x86 (like ppc for
> > powerpc)? and then it is able to only resereve the variables for x86_64. I have
> > prepared a patch for this goal in our new tinyconfig patchset, it will further
> > avoid adding the same nolibc-test-x86.config and nolibc-test-x86_64.config.
> 
> I'm confused, x86 already defaults to x86_64, it's just that it depends
> on the .config itself to figure whether to produce a 32- or 64-bit kernel.
> But for example it starts qemu in 64-bit mode. Am I missing anything ?
>

In kernel side, it is, but in our nolibc-test, we have added a copy of x86_64
for x86:

    $ grep -E "_x86" tools/testing/selftests/nolibc/Makefile 
    IMAGE_x86_64     = arch/x86/boot/bzImage
    IMAGE_x86        = arch/x86/boot/bzImage
    CROSS_COMPILE_x86_64    ?= x86_64-linux- x86_64-linux-gnu-
    CROSS_COMPILE_x86       ?= x86_64-linux- x86_64-linux-gnu-
    DEFCONFIG_x86_64     = defconfig
    DEFCONFIG_x86        = defconfig
    QEMU_ARCH_x86_64     = x86_64
    QEMU_ARCH_x86        = x86_64
    QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
    QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"

With 'XARCH', the "_x86" copy of them can be simply replaced with such a line:

     # configure default variants for target kernel supported architectures
     XARCH_powerpc    = ppc
    +XARCH_x86        = x86_64
     XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))

And therefore, the future nolibc-test-x86_64.config is also enough for x86.

But I have seen the 'x86' exception in tools/include/nolibc/Makefile, just a
confirm on if this replacement is ok.

BR,
Zhangjin

> Willy
  

On Mon, Aug 14, 2023 at 03:38:54PM +0800, Zhangjin Wu wrote:
> > On Sun, Aug 13, 2023 at 06:05:03PM +0800, Zhangjin Wu wrote:
> > > > I think that later I'll further extend XARCH with new variants to
> > > > support ARMv5 and Thumb2, because we have different code for this
> > > > and I continue to manually change the CFLAGS to test both.
> > > >
> > > 
> > > Ok, what about further add x86_64 as the default variant for x86 (like ppc for
> > > powerpc)? and then it is able to only resereve the variables for x86_64. I have
> > > prepared a patch for this goal in our new tinyconfig patchset, it will further
> > > avoid adding the same nolibc-test-x86.config and nolibc-test-x86_64.config.
> > 
> > I'm confused, x86 already defaults to x86_64, it's just that it depends
> > on the .config itself to figure whether to produce a 32- or 64-bit kernel.
> > But for example it starts qemu in 64-bit mode. Am I missing anything ?
> >
> 
> In kernel side, it is, but in our nolibc-test, we have added a copy of x86_64
> for x86:
> 
>     $ grep -E "_x86" tools/testing/selftests/nolibc/Makefile 
>     IMAGE_x86_64     = arch/x86/boot/bzImage
>     IMAGE_x86        = arch/x86/boot/bzImage
>     CROSS_COMPILE_x86_64    ?= x86_64-linux- x86_64-linux-gnu-
>     CROSS_COMPILE_x86       ?= x86_64-linux- x86_64-linux-gnu-
>     DEFCONFIG_x86_64     = defconfig
>     DEFCONFIG_x86        = defconfig
>     QEMU_ARCH_x86_64     = x86_64
>     QEMU_ARCH_x86        = x86_64
>     QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
>     QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> 
> With 'XARCH', the "_x86" copy of them can be simply replaced with such a line:
> 
>      # configure default variants for target kernel supported architectures
>      XARCH_powerpc    = ppc
>     +XARCH_x86        = x86_64
>      XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))
> 
> And therefore, the future nolibc-test-x86_64.config is also enough for x86.
> 
> But I have seen the 'x86' exception in tools/include/nolibc/Makefile, just a
> confirm on if this replacement is ok.

Ah I thought you meant the opposite, i.e. that ppc did map to powerpc
that I was not seeing anywhere else. Yes we can probably do that and
remove the x86-specific lines later.

Willy
  

On Mon, Aug 14, 2023 at 10:25:00AM +0200, Willy Tarreau wrote:
> On Mon, Aug 14, 2023 at 03:38:54PM +0800, Zhangjin Wu wrote:
> > > On Sun, Aug 13, 2023 at 06:05:03PM +0800, Zhangjin Wu wrote:
> > > > > I think that later I'll further extend XARCH with new variants to
> > > > > support ARMv5 and Thumb2, because we have different code for this
> > > > > and I continue to manually change the CFLAGS to test both.
> > > > >
> > > > 
> > > > Ok, what about further add x86_64 as the default variant for x86 (like ppc for
> > > > powerpc)? and then it is able to only resereve the variables for x86_64. I have
> > > > prepared a patch for this goal in our new tinyconfig patchset, it will further
> > > > avoid adding the same nolibc-test-x86.config and nolibc-test-x86_64.config.
> > > 
> > > I'm confused, x86 already defaults to x86_64, it's just that it depends
> > > on the .config itself to figure whether to produce a 32- or 64-bit kernel.
> > > But for example it starts qemu in 64-bit mode. Am I missing anything ?
> > >
> > 
> > In kernel side, it is, but in our nolibc-test, we have added a copy of x86_64
> > for x86:
> > 
> >     $ grep -E "_x86" tools/testing/selftests/nolibc/Makefile 
> >     IMAGE_x86_64     = arch/x86/boot/bzImage
> >     IMAGE_x86        = arch/x86/boot/bzImage
> >     CROSS_COMPILE_x86_64    ?= x86_64-linux- x86_64-linux-gnu-
> >     CROSS_COMPILE_x86       ?= x86_64-linux- x86_64-linux-gnu-
> >     DEFCONFIG_x86_64     = defconfig
> >     DEFCONFIG_x86        = defconfig
> >     QEMU_ARCH_x86_64     = x86_64
> >     QEMU_ARCH_x86        = x86_64
> >     QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> >     QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> > 
> > With 'XARCH', the "_x86" copy of them can be simply replaced with such a line:
> > 
> >      # configure default variants for target kernel supported architectures
> >      XARCH_powerpc    = ppc
> >     +XARCH_x86        = x86_64
> >      XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))
> > 
> > And therefore, the future nolibc-test-x86_64.config is also enough for x86.
> > 
> > But I have seen the 'x86' exception in tools/include/nolibc/Makefile, just a
> > confirm on if this replacement is ok.
> 
> Ah I thought you meant the opposite, i.e. that ppc did map to powerpc
> that I was not seeing anywhere else. Yes we can probably do that and
> remove the x86-specific lines later.

by "later" I mean "further" in the file.

Willy