[Buildroot] Toolchain issues on multiple architectures

[Buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

Hello,

As part of the https://toolchains.bootlin.com project, I've tried to
rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
number of failures, which are summarized below.

Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
Could you have a look, and tell us if you have some suggestions?

ARC maintainers: all ARC toolchains are failing to build due to the use
of a recent gdb where gdbserver was moved to the top-level. However, it
doesn't seem to be that easy to build just gdbserver in those recent
gcc versions. I have posted a question about this on the gdb@ mailing
list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.

Matt, there are some PowerPC64 build issues as well. Have you ever seen
them, do you have any hints?

There are also issues on other platforms, AArch64, x86-64, Microblaze, etc.

See below the full details:

AArch64
=======

- aarch64--musl--stable
  https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359478

  build failure while building gdb, with redefinitions of C library
  structures

ARC
===

All configurations are failing

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359481
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359482
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359483
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359484
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359485
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359487

Issue is caused by the recent version of gdb, where gdbserver has been
moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
simple: you can't simply go in gdbserver/ and run ./configure from it,
that doesn't work anymore.

ARMv7-M
=======

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359529

Build failures while building afboot-stm32, most likely due to gcc
10.x emitting calls to memcpy().

Fixed by:

https://patchwork.ozlabs.org/project/buildroot/patch/20200910094608.1251382-1-thomas.petazzoni at bootlin.com/

Microblaze
==========

All the "bleeding edge" configurations fail to boot under Qemu.

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359536
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359538
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359540
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546

PowerPC64 (big and little endian) Power 8
=========================================

Both the glibc stable and bleeding edge are failing to build libstdc++
in host-gcc-final. Interesingly, the musl configurations work fine.

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622

RISC-V ILP32D
=============

The only configuration (glibc) fails to build in glibc, with a bunch
of:

../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function); did you mean '__futex'?
  120 | #define SYS_ify(syscall_name) __NR_##syscall_name

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359659

SPARCv8
=======

Fortran support related issue:

/builds/bootlin/toolchains-builder/build/opt/sparcv8--uclibc--stable-2020.08-1/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: /builds/bootlin/toolchains-builder/build/opt/sparcv8--uclibc--stable-2020.08-1/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/lib/libgfortran.so: undefined reference to `__sync_bool_compare_and_swap_4'
collect2: error: ld returned 1 exit status

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359681
- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359683

SPARCv8 doesn't have __sync built-ins of 4 bytes, so probably we
should not allow Fortran support on SPARCv8 ?

x86-64
======

Issue happens only with the uClibc bleeding edge toolchain: it seems
like it cannot login into the system under Qemu. The login prompt
appears, but then it doesn't seem to work.

- https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359690


-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Matthew Weber]

On Thu, Sep 10, 2020 at 5:06 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> As part of the https://toolchains.bootlin.com project, I've tried to
> rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> number of failures, which are summarized below.
>
> Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> Could you have a look, and tell us if you have some suggestions?
>
> ARC maintainers: all ARC toolchains are failing to build due to the use
> of a recent gdb where gdbserver was moved to the top-level. However, it
> doesn't seem to be that easy to build just gdbserver in those recent
> gcc versions. I have posted a question about this on the gdb@ mailing
> list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
>
> Matt, there are some PowerPC64 build issues as well. Have you ever seen
> them, do you have any hints?
>
> There are also issues on other platforms, AArch64, x86-64, Microblaze, etc.
>
> See below the full details:
>
> AArch64
> =======
>
> - aarch64--musl--stable
>   https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359478
>
>   build failure while building gdb, with redefinitions of C library
>   structures
>
> ARC
> ===
>
> All configurations are failing
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359481
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359482
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359483
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359484
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359485
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359487
>
> Issue is caused by the recent version of gdb, where gdbserver has been
> moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> simple: you can't simply go in gdbserver/ and run ./configure from it,
> that doesn't work anymore.
>
> ARMv7-M
> =======
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359529
>
> Build failures while building afboot-stm32, most likely due to gcc
> 10.x emitting calls to memcpy().
>
> Fixed by:
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20200910094608.1251382-1-thomas.petazzoni at bootlin.com/
>
> Microblaze
> ==========
>
> All the "bleeding edge" configurations fail to boot under Qemu.
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359536
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359538
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359540
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546
>
> PowerPC64 (big and little endian) Power 8
> =========================================
>
> Both the glibc stable and bleeding edge are failing to build libstdc++
> in host-gcc-final. Interesingly, the musl configurations work fine.
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622

Checking out 2020.08 and using the following config from the CI job.
BR2_powerpc64le=y
BR2_powerpc_power8=y
BR2_KERNEL_HEADERS_4_9=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
BR2_PACKAGE_HOST_GDB=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_GDB=y
# BR2_TARGET_ROOTFS_TAR is not set

I see this error:
../../../libgfortran/libgfortran.h:61:12: fatal error:
quadmath_weak.h: No such file or directory

I did notice that if I did a basic build below using current defaults,
it doesn't fail.
BR2_powerpc64=y
BR2_powerpc_power8=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_INIT_NONE=y
# BR2_TARGET_ROOTFS_TAR is not set

I'll do some analysis between the builds

Best Regards,
Matt

[Buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

On Thu, 10 Sep 2020 09:43:21 -0500
Matthew Weber <matthew.weber@collins.com> wrote:

> Checking out 2020.08 and using the following config from the CI job.
> BR2_powerpc64le=y
> BR2_powerpc_power8=y
> BR2_KERNEL_HEADERS_4_9=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> BR2_PACKAGE_HOST_GDB=y
> BR2_INIT_NONE=y
> BR2_SYSTEM_BIN_SH_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_GDB=y
> # BR2_TARGET_ROOTFS_TAR is not set
> 
> I see this error:
> ../../../libgfortran/libgfortran.h:61:12: fatal error:
> quadmath_weak.h: No such file or directory

Ah, so it's enabling the Fortran support that makes it fail to build. I
see that it is including quadmath_weak.h only if HAVE_FLOAT128 is
enabled:

#ifdef HAVE_FLOAT128
#  include "quadmath_weak.h"
#endif

I suppose PowerPC64 has HAVE_FLOAT128 enabled, and not other
architectures ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82292 has some context,
and concludes with "Yeah, I think this is user error.". Seems like
we're not passing the appropriate enable/disable libquadmath options.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Matthew Weber]

On Thu, Sep 10, 2020 at 9:43 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> On Thu, Sep 10, 2020 at 5:06 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > As part of the https://toolchains.bootlin.com project, I've tried to
> > rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> > number of failures, which are summarized below.
> >
> > Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> > Could you have a look, and tell us if you have some suggestions?
> >
> > ARC maintainers: all ARC toolchains are failing to build due to the use
> > of a recent gdb where gdbserver was moved to the top-level. However, it
> > doesn't seem to be that easy to build just gdbserver in those recent
> > gcc versions. I have posted a question about this on the gdb@ mailing
> > list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
> >
> > Matt, there are some PowerPC64 build issues as well. Have you ever seen
> > them, do you have any hints?
> >
[snip]
> > PowerPC64 (big and little endian) Power 8
> > =========================================
> >
> > Both the glibc stable and bleeding edge are failing to build libstdc++
> > in host-gcc-final. Interesingly, the musl configurations work fine.
> >
> > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
> > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
> > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
> > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622
>
> Checking out 2020.08 and using the following config from the CI job.
> BR2_powerpc64le=y
> BR2_powerpc_power8=y
> BR2_KERNEL_HEADERS_4_9=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> BR2_PACKAGE_HOST_GDB=y
> BR2_INIT_NONE=y
> BR2_SYSTEM_BIN_SH_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_GDB=y
> # BR2_TARGET_ROOTFS_TAR is not set
>
> I see this error:
> ../../../libgfortran/libgfortran.h:61:12: fatal error:
> quadmath_weak.h: No such file or directory
>
> I did notice that if I did a basic build below using current defaults,
> it doesn't fail.
> BR2_powerpc64=y
> BR2_powerpc_power8=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_INIT_NONE=y
> # BR2_TARGET_ROOTFS_TAR is not set

Disregard the successful build above, I forgot to enable fortran.

It looks like the powerpc64 is detecting __float128 and is trying to
use the quadmath library which we disable.  I'll check to see if the
change should be in the libfortran configure stage or what is being
passed to gcc final.

Regards,
Matt

[Buildroot] [arc-buildroot] Toolchain issues on multiple architectures

[Alexey Brodkin]

Hi Thomas,

> As part of the https://toolchains.bootlin.com/  project, I've tried to
> rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> number of failures, which are summarized below.

[snip]
 
> ARC maintainers: all ARC toolchains are failing to build due to the use
> of a recent gdb where gdbserver was moved to the top-level. However, it
> doesn't seem to be that easy to build just gdbserver in those recent
> gcc versions. I have posted a question about this on the gdb@ mailing
> list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.

[snip]

> ARC
> ===
> 
> All configurations are failing.
> 
> Issue is caused by the recent version of gdb, where gdbserver has been
> moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> simple: you can't simply go in gdbserver/ and run ./configure from it,
> that doesn't work anymore.

But in your exercise mentioned above do you really need only gdbserver?
I understand that full GDB might be quite an overkill for a tiny target but
it might not be installed onto the target rootfs, right?

So what if for GDB 10+ we'll add an installation quirk which will remove
full GDB from "output/target" if we only want gdbsever?

-Alexey

[Buildroot] Toolchain issues on multiple architectures

[Matthew Weber]

On Thu, Sep 10, 2020 at 10:43 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> On Thu, Sep 10, 2020 at 9:43 AM Matthew Weber
> <matthew.weber@rockwellcollins.com> wrote:
> >
> > On Thu, Sep 10, 2020 at 5:06 AM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> > >
> > > Hello,
> > >
> > > As part of the https://toolchains.bootlin.com project, I've tried to
> > > rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> > > number of failures, which are summarized below.
> > >
> > > Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> > > Could you have a look, and tell us if you have some suggestions?
> > >
> > > ARC maintainers: all ARC toolchains are failing to build due to the use
> > > of a recent gdb where gdbserver was moved to the top-level. However, it
> > > doesn't seem to be that easy to build just gdbserver in those recent
> > > gcc versions. I have posted a question about this on the gdb@ mailing
> > > list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
> > >
> > > Matt, there are some PowerPC64 build issues as well. Have you ever seen
> > > them, do you have any hints?
> > >
> [snip]
> > > PowerPC64 (big and little endian) Power 8
> > > =========================================
> > >
> > > Both the glibc stable and bleeding edge are failing to build libstdc++
> > > in host-gcc-final. Interesingly, the musl configurations work fine.
> > >
> > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
> > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
> > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
> > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622
> >
> > Checking out 2020.08 and using the following config from the CI job.
> > BR2_powerpc64le=y
> > BR2_powerpc_power8=y
> > BR2_KERNEL_HEADERS_4_9=y
> > BR2_TOOLCHAIN_BUILDROOT_CXX=y
> > BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> > BR2_PACKAGE_HOST_GDB=y
> > BR2_INIT_NONE=y
> > BR2_SYSTEM_BIN_SH_NONE=y
> > # BR2_PACKAGE_BUSYBOX is not set
> > BR2_PACKAGE_GDB=y
> > # BR2_TARGET_ROOTFS_TAR is not set
> >
> > I see this error:
> > ../../../libgfortran/libgfortran.h:61:12: fatal error:
> > quadmath_weak.h: No such file or directory
> >
> > I did notice that if I did a basic build below using current defaults,
> > it doesn't fail.
> > BR2_powerpc64=y
> > BR2_powerpc_power8=y
> > BR2_TOOLCHAIN_BUILDROOT_CXX=y
> > BR2_INIT_NONE=y
> > # BR2_TARGET_ROOTFS_TAR is not set
>
> Disregard the successful build above, I forgot to enable fortran.
>
> It looks like the powerpc64 is detecting __float128 and is trying to
> use the quadmath library which we disable.  I'll check to see if the
> change should be in the libfortran configure stage or what is being
> passed to gcc final.

My original understanding was that just the IBM families with ISA 3.0+
could do float128 [1].  Turns out any Power ISA v.2.06+ (64bit powerpc
NXP & IBM) should be able to have quadmath enabled and the stdlib may
emulate as needed [2].

I'm still testing a series of builds (e5500, e6500, power6/7/8) but I
believe the fix is to just add power64(big/le) to the condition to
enable quadmath (BR2_TOOLCHAIN_HAS_LIBQUADMATH).

config BR2_TOOLCHAIN_HAS_LIBQUADMATH
        bool
        default y if BR2_i386 || BR2_x86_64 || BR2_powerpc64 || BR2_powerpc64le

Are you able to make this change in your toolchain builder branch of
buildroot and validate the IBM and e5500 toolchains create images that
can login?  I can send a patch to the mailing list as well


Regards,
Matt

[1] https://en.wikipedia.org/wiki/Power_ISA
[2] https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

[Buildroot] Toolchain issues on multiple architectures

[Alistair Francis]

On Thu, Sep 10, 2020 at 3:05 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> As part of the https://toolchains.bootlin.com project, I've tried to
> rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> number of failures, which are summarized below.
>
> Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> Could you have a look, and tell us if you have some suggestions?
>
> ARC maintainers: all ARC toolchains are failing to build due to the use
> of a recent gdb where gdbserver was moved to the top-level. However, it
> doesn't seem to be that easy to build just gdbserver in those recent
> gcc versions. I have posted a question about this on the gdb@ mailing
> list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
>
> Matt, there are some PowerPC64 build issues as well. Have you ever seen
> them, do you have any hints?
>
> There are also issues on other platforms, AArch64, x86-64, Microblaze, etc.
>
> See below the full details:
>
> AArch64
> =======
>
> - aarch64--musl--stable
>   https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359478
>
>   build failure while building gdb, with redefinitions of C library
>   structures
>
> ARC
> ===
>
> All configurations are failing
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359481
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359482
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359483
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359484
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359485
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359487
>
> Issue is caused by the recent version of gdb, where gdbserver has been
> moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> simple: you can't simply go in gdbserver/ and run ./configure from it,
> that doesn't work anymore.
>
> ARMv7-M
> =======
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359529
>
> Build failures while building afboot-stm32, most likely due to gcc
> 10.x emitting calls to memcpy().
>
> Fixed by:
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20200910094608.1251382-1-thomas.petazzoni at bootlin.com/
>
> Microblaze
> ==========
>
> All the "bleeding edge" configurations fail to boot under Qemu.
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359536
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359538
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359540
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546
>
> PowerPC64 (big and little endian) Power 8
> =========================================
>
> Both the glibc stable and bleeding edge are failing to build libstdc++
> in host-gcc-final. Interesingly, the musl configurations work fine.
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622
>
> RISC-V ILP32D
> =============
>
> The only configuration (glibc) fails to build in glibc, with a bunch
> of:
>
> ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function); did you mean '__futex'?
>   120 | #define SYS_ify(syscall_name) __NR_##syscall_name
>
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359659

Do you have any steps to reproduce this?

I tried `make qemu_riscv32_virt_defconfig; make` in buildroot and I
don't see any failures.

I tried `./build.sh riscv32-ilp32d--glibc--bleeding-edge testing
buildroot-toolchains/toolchains.bootlin.com-2020.08 2020.08-1` in the
toolchains-builder, but I'm missing
frags/riscv32-ilp32d--glibc--bleeding-edge.config.

I then tried `frags/riscv32-ilp32d--glibc--bleeding-edge.config` but
it doesn't generate a RV32 frag.

What am I missing?

Alistair

[Buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

Hello Alistair,

On Thu, 10 Sep 2020 16:17:46 -0700
Alistair Francis <alistair23@gmail.com> wrote:

> Do you have any steps to reproduce this?

You need to build this defconfig:

BR2_riscv=y
BR2_RISCV_32=y
BR2_KERNEL_HEADERS_5_4=y
BR2_BINUTILS_VERSION_2_34_X=y
BR2_GCC_VERSION_10_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_GDB=y
# BR2_TARGET_ROOTFS_TAR is not set

> I tried `./build.sh riscv32-ilp32d--glibc--bleeding-edge testing
> buildroot-toolchains/toolchains.bootlin.com-2020.08 2020.08-1` in the
> toolchains-builder, but I'm missing
> frags/riscv32-ilp32d--glibc--bleeding-edge.config.
> 
> I then tried `frags/riscv32-ilp32d--glibc--bleeding-edge.config` but
> it doesn't generate a RV32 frag.

I don't recommend trying to use the toolchains-builder stuff. For now
it's not really designed to be executed locally. This is something I
want to fix, but I'm not there yet.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [arc-buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

Hello,

On Thu, 10 Sep 2020 16:39:18 +0000
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> > Issue is caused by the recent version of gdb, where gdbserver has been
> > moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> > simple: you can't simply go in gdbserver/ and run ./configure from it,
> > that doesn't work anymore.  
> 
> But in your exercise mentioned above do you really need only gdbserver?
> I understand that full GDB might be quite an overkill for a tiny target but
> it might not be installed onto the target rootfs, right?

I'm building cross-compilation toolchains, in which we only want
gdbserver for the target, not the full gdb.

> So what if for GDB 10+ we'll add an installation quirk which will remove
> full GDB from "output/target" if we only want gdbsever?

Building the full blown gdb would also require building its
dependencies, i.e ncurses and possibly libiconv. Building only
gdbserver allows to avoid that.

I've got some feedback from upstream though, they pointed to:

  https://github.com/bminor/binutils-gdb/blob/master/gdbserver/README#L86

which explains what is the supported way of building just gdbserver.
We'll have to test this, and see if it works not only with recent GDB,
but also older GDB versions that we still support.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [arc-buildroot] Toolchain issues on multiple architectures

[Alexey Brodkin]

Hi Thomas,

> On Thu, 10 Sep 2020 16:39:18 +0000
> Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> 
> > > Issue is caused by the recent version of gdb, where gdbserver has been
> > > moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> > > simple: you can't simply go in gdbserver/ and run ./configure from it,
> > > that doesn't work anymore. ?
> > 
> > But in your exercise mentioned above do you really need only gdbserver?
> > I understand that full GDB might be quite an overkill for a tiny target but
> > it might not be installed onto the target rootfs, right?
> 
> I'm building cross-compilation toolchains, in which we only want
> gdbserver for the target, not the full gdb.
> 
> > So what if for GDB 10+ we'll add an installation quirk which will remove
> > full GDB from "output/target" if we only want gdbsever?
> 
> Building the full blown gdb would also require building its
> dependencies, i.e ncurses and possibly libiconv. Building only
> gdbserver allows to avoid that.
> 
> I've got some feedback from upstream though, they pointed to:
> ? https://github.com/bminor/binutils-gdb/blob/master/gdbserver/README#L86 
> 
> which explains what is the supported way of building just gdbserver.
> We'll have to test this, and see if it works not only with recent GDB,
> but also older GDB versions that we still support.

That's an interesting finding indeed.
So do you need any further help with that from our side now?

BTW I was eagerly waiting for the next official GDB release
(v10, which was supposed to happen a while ago according to
https://www.gnu.org/software/gdb/schedule/) so that we may come-up with a more
generic solution rather than just ARC quirk but the reality is there's no release
and no ETAs I'm aware of so most probably we'll need to come-up with a custom
quirk for now :(

-Alexey

[Buildroot] Toolchain issues on multiple architectures

[Matthew Weber]

On Thu, Sep 10, 2020 at 11:55 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> On Thu, Sep 10, 2020 at 10:43 AM Matthew Weber
> <matthew.weber@rockwellcollins.com> wrote:
> >
> > On Thu, Sep 10, 2020 at 9:43 AM Matthew Weber
> > <matthew.weber@rockwellcollins.com> wrote:
> > >
> > > On Thu, Sep 10, 2020 at 5:06 AM Thomas Petazzoni
> > > <thomas.petazzoni@bootlin.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > As part of the https://toolchains.bootlin.com project, I've tried to
> > > > rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> > > > number of failures, which are summarized below.
> > > >
> > > > Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> > > > Could you have a look, and tell us if you have some suggestions?
> > > >
> > > > ARC maintainers: all ARC toolchains are failing to build due to the use
> > > > of a recent gdb where gdbserver was moved to the top-level. However, it
> > > > doesn't seem to be that easy to build just gdbserver in those recent
> > > > gcc versions. I have posted a question about this on the gdb@ mailing
> > > > list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
> > > >
> > > > Matt, there are some PowerPC64 build issues as well. Have you ever seen
> > > > them, do you have any hints?
> > > >
> > [snip]
> > > > PowerPC64 (big and little endian) Power 8
> > > > =========================================
> > > >
> > > > Both the glibc stable and bleeding edge are failing to build libstdc++
> > > > in host-gcc-final. Interesingly, the musl configurations work fine.
> > > >
> > > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359625
> > > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359626
> > > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359621
> > > > - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359622
> > >

http://patchwork.ozlabs.org/project/buildroot/patch/20200911124131.8549-1-matthew.weber at rockwellcollins.com/

Regards,
Matt

[Buildroot] Toolchain issues on multiple architectures

[Alistair Francis]

On Fri, Sep 11, 2020 at 12:30 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Alistair,
>
> On Thu, 10 Sep 2020 16:17:46 -0700
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > Do you have any steps to reproduce this?
>
> You need to build this defconfig:
>
> BR2_riscv=y
> BR2_RISCV_32=y
> BR2_KERNEL_HEADERS_5_4=y
> BR2_BINUTILS_VERSION_2_34_X=y
> BR2_GCC_VERSION_10_X=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> BR2_INIT_NONE=y
> BR2_SYSTEM_BIN_SH_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_GDB=y
> # BR2_TARGET_ROOTFS_TAR is not set

I don't see any errors using this config with buildroot. Do I need to
do anything else?

>
> > I tried `./build.sh riscv32-ilp32d--glibc--bleeding-edge testing
> > buildroot-toolchains/toolchains.bootlin.com-2020.08 2020.08-1` in the
> > toolchains-builder, but I'm missing
> > frags/riscv32-ilp32d--glibc--bleeding-edge.config.
> >
> > I then tried `frags/riscv32-ilp32d--glibc--bleeding-edge.config` but
> > it doesn't generate a RV32 frag.
>
> I don't recommend trying to use the toolchains-builder stuff. For now
> it's not really designed to be executed locally. This is something I
> want to fix, but I'm not there yet.

No worries.

Alistair

>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

Hello Alistair,

On Fri, 11 Sep 2020 09:03:23 -0700
Alistair Francis <alistair23@gmail.com> wrote:

> > BR2_riscv=y
> > BR2_RISCV_32=y
> > BR2_KERNEL_HEADERS_5_4=y
> > BR2_BINUTILS_VERSION_2_34_X=y
> > BR2_GCC_VERSION_10_X=y
> > BR2_TOOLCHAIN_BUILDROOT_CXX=y
> > BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> > BR2_INIT_NONE=y
> > BR2_SYSTEM_BIN_SH_NONE=y
> > # BR2_PACKAGE_BUSYBOX is not set
> > BR2_PACKAGE_GDB=y
> > # BR2_TARGET_ROOTFS_TAR is not set  
> 
> I don't see any errors using this config with buildroot. Do I need to
> do anything else?

Sorry for the slow feedback. I retested the above defconfig, and it
fails to build here. Did you try on the 2020.08 tag, with no change ?
Perhaps you tried on master and something fixed this on master after
2020.08 ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Alistair Francis]

On Thu, Sep 24, 2020 at 2:42 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Alistair,
>
> On Fri, 11 Sep 2020 09:03:23 -0700
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > > BR2_riscv=y
> > > BR2_RISCV_32=y
> > > BR2_KERNEL_HEADERS_5_4=y
> > > BR2_BINUTILS_VERSION_2_34_X=y
> > > BR2_GCC_VERSION_10_X=y
> > > BR2_TOOLCHAIN_BUILDROOT_CXX=y
> > > BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
> > > BR2_INIT_NONE=y
> > > BR2_SYSTEM_BIN_SH_NONE=y
> > > # BR2_PACKAGE_BUSYBOX is not set
> > > BR2_PACKAGE_GDB=y
> > > # BR2_TARGET_ROOTFS_TAR is not set
> >
> > I don't see any errors using this config with buildroot. Do I need to
> > do anything else?
>
> Sorry for the slow feedback. I retested the above defconfig, and it
> fails to build here. Did you try on the 2020.08 tag, with no change ?
> Perhaps you tried on master and something fixed this on master after
> 2020.08 ?

Yep, that doesn't work.

That branch is missing the patches to use upstream glibc:

* acc1330d4a configs/qemu_riscv32_virt: use Linux 5.4 kernel (by
Alistair Francis 3 weeks ago)
* a4889545aa package/glibc: use upstream glibc for RISC-V 32-bit (by
Alistair Francis 3 weeks ago)

Because of that the kernel headers need to be patched to add support
for a 32-bit time_t.

This change in the defconfig should fix that:

BR2_GLOBAL_PATCH_DIR="board/qemu/riscv32-virt/patches/"

Although it looks like the kernel build is also required to get the
patches to take effect:

# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
BR2_LINUX_KERNEL_DEFCONFIG="rv32"
BR2_LINUX_KERNEL_IMAGE=y

Although applying the two commits mentioned above would be a much better option.


Alistair

>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Bernd Kuhls]

Am Thu, 24 Sep 2020 11:42:04 +0200 schrieb Thomas Petazzoni:

> Perhaps you tried on master and something fixed this on master after
> 2020.08 ?

Hi,

never tried to build specifically for risc-v before but being curious I 
tried to reproduce the problem and yes: 2020.08 fails, master works.

To fix the problem with 2020.08 please cherry-pick
https://git.buildroot.net/buildroot/commit/?id=a4889545aa

Regards, Bernd

[Buildroot] Toolchain issues on multiple architectures

[Thomas Petazzoni]

Hello,

On Thu, 24 Sep 2020 11:20:18 -0700
Alistair Francis <alistair23@gmail.com> wrote:

> > Sorry for the slow feedback. I retested the above defconfig, and it
> > fails to build here. Did you try on the 2020.08 tag, with no change ?
> > Perhaps you tried on master and something fixed this on master after
> > 2020.08 ?  
> 
> Yep, that doesn't work.
> 
> That branch is missing the patches to use upstream glibc:
> 
> * acc1330d4a configs/qemu_riscv32_virt: use Linux 5.4 kernel (by
> Alistair Francis 3 weeks ago)
> * a4889545aa package/glibc: use upstream glibc for RISC-V 32-bit (by
> Alistair Francis 3 weeks ago)
> 
> Because of that the kernel headers need to be patched to add support
> for a 32-bit time_t.
> 
> This change in the defconfig should fix that:
> 
> BR2_GLOBAL_PATCH_DIR="board/qemu/riscv32-virt/patches/"
> 
> Although it looks like the kernel build is also required to get the
> patches to take effect:
> 
> # Kernel
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> BR2_LINUX_KERNEL_IMAGE=y
> 
> Although applying the two commits mentioned above would be a much better option.

Thanks a lot for the feedback, it makes sense. To me, it illustrates
very well that the solution of having patches for the kernel headers
that only apply to a specific defconfig doesn't work: whenever someone
builds a system from scratch without using a defconfig, such patches
are not applied.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Alistair Francis]

On Thu, Sep 24, 2020 at 11:47 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Thu, 24 Sep 2020 11:20:18 -0700
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > > Sorry for the slow feedback. I retested the above defconfig, and it
> > > fails to build here. Did you try on the 2020.08 tag, with no change ?
> > > Perhaps you tried on master and something fixed this on master after
> > > 2020.08 ?
> >
> > Yep, that doesn't work.
> >
> > That branch is missing the patches to use upstream glibc:
> >
> > * acc1330d4a configs/qemu_riscv32_virt: use Linux 5.4 kernel (by
> > Alistair Francis 3 weeks ago)
> > * a4889545aa package/glibc: use upstream glibc for RISC-V 32-bit (by
> > Alistair Francis 3 weeks ago)
> >
> > Because of that the kernel headers need to be patched to add support
> > for a 32-bit time_t.
> >
> > This change in the defconfig should fix that:
> >
> > BR2_GLOBAL_PATCH_DIR="board/qemu/riscv32-virt/patches/"
> >
> > Although it looks like the kernel build is also required to get the
> > patches to take effect:
> >
> > # Kernel
> > BR2_LINUX_KERNEL=y
> > BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> > BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> > BR2_LINUX_KERNEL_IMAGE=y
> >
> > Although applying the two commits mentioned above would be a much better option.
>
> Thanks a lot for the feedback, it makes sense. To me, it illustrates
> very well that the solution of having patches for the kernel headers
> that only apply to a specific defconfig doesn't work: whenever someone
> builds a system from scratch without using a defconfig, such patches
> are not applied.

Yep, makes sense. Luckily we no longer need them for RV32 :)

Alistair

>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] Toolchain issues on multiple architectures

[Romain Naour]

Hello Thomas,

Le 10/09/2020 ? 12:05, Thomas Petazzoni a ?crit?:
> Hello,
> 
> As part of the https://toolchains.bootlin.com project, I've tried to
> rebuild 175 toolchains on top of Buildroot 2020.08, and encountered a
> number of failures, which are summarized below.
> 
> Damien, Alistair: there is an issue with the RISC-V 32-bit toolchain.
> Could you have a look, and tell us if you have some suggestions?
> 
> ARC maintainers: all ARC toolchains are failing to build due to the use
> of a recent gdb where gdbserver was moved to the top-level. However, it
> doesn't seem to be that easy to build just gdbserver in those recent
> gcc versions. I have posted a question about this on the gdb@ mailing
> list: https://sourceware.org/pipermail/gdb/2020-September/048888.html.
> 
> Matt, there are some PowerPC64 build issues as well. Have you ever seen
> them, do you have any hints?
> 
> There are also issues on other platforms, AArch64, x86-64, Microblaze, etc.
> 
> See below the full details:
> 
> AArch64
> =======
> 
> - aarch64--musl--stable
>   https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359478
> 
>   build failure while building gdb, with redefinitions of C library
>   structures

This is our usual aarch64 + musl + gdb issue due to the kernel headers < 5.0.
You already fixed it by applying a patch to linux-headers package to a custom
branch in the bootlin repository.

Maybe we should use kernel headers 5.4 for the bleeding-edge toolchain since we
use a kernel 5.4 in the qemu defconfig.
(Is the kernel headers 5.4 too bleeding-edge for bleeding-edge toolchains ? :) )

> 
> Microblaze
> ==========
> 
> All the "bleeding edge" configurations fail to boot under Qemu.
> 
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359536
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359538
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359540
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546

I'm not sure there is a regular Maintainer for Microblaze

For example, last time glibc has been tested on Microblaze
https://sourceware.org/glibc/wiki/Release/2.29#MicroBlaze

https://sourceware.org/glibc/wiki/Release/2.30#MicroBlaze
https://sourceware.org/glibc/wiki/Release/2.31#MicroBlaze
https://sourceware.org/glibc/wiki/Release/2.32#MicroBlaze

I'll to take a look...

> 
> SPARCv8
> =======
> 
> Fortran support related issue:
> 
> /builds/bootlin/toolchains-builder/build/opt/sparcv8--uclibc--stable-2020.08-1/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: /builds/bootlin/toolchains-builder/build/opt/sparcv8--uclibc--stable-2020.08-1/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/lib/libgfortran.so: undefined reference to `__sync_bool_compare_and_swap_4'
> collect2: error: ld returned 1 exit status
> 
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359681
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359683
> 
> SPARCv8 doesn't have __sync built-ins of 4 bytes, so probably we
> should not allow Fortran support on SPARCv8 ?

See patch proposal:
http://patchwork.ozlabs.org/project/buildroot/patch/20200925090451.1407258-1-romain.naour at gmail.com/

> 
> x86-64
> ======
> 
> Issue happens only with the uClibc bleeding edge toolchain: it seems
> like it cannot login into the system under Qemu. The login prompt
> appears, but then it doesn't seem to work.
> 
> - https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359690

See:
https://github.com/bootlin/toolchains-builder/pull/36

Best regards,
Romain