As reported on IRC by sephthir, the qemu_sparc_ss10_defconfig doesn't
work as expected: the system generated when booted under Qemu produces
illegal instruction messages.
gcc 8.3, 9.2 are the latest working gcc version. git bisect between
gcc 8.3 and 8.4 allowed to identify the commit that introcuced the
regression.
Reverting this patch allowed to produce a working rootfs.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/786589934
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4d16e6f532)
[Peter: drop GCC 10.x patch]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As we many times by now discussed that - some ARC cores might
not have atomic instructions implemented. Namely that's ARC700
w/o explicitly added atomics during design creation/configuration.
Because of that when GCC gets configured for ARC700, i.e. via
"--with-cpu=arc700" atomic ops are assumed disabled.
Usually it's not a problem as we add "-matomics" in the wraper for
building all packages if targets CPU has atomis (BR2_ARC_ATOMIC_EXT).
But when bulding target's binaries which are essential parts of
the GCC itself we don't use the wrapper. Instead xgcc is being used.
That way we lose that important part of system's configuration about
atomics and:
1. Atomic ops won't be used where otherwise they could have been used.
2. Some configuration checks might end-up thinking there're no atomics
In particular (2) leads to pretty obscure failure on bulding of some
packages which use C++, for example:
log4cplus: http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7
------------------------>8--------------------
./.libs/liblog4cplus.so: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
collect2: error: ld returned 1 exit status
------------------------>8--------------------
bitcoin: http://autobuild.buildroot.net/results/f73/f73d4c77e5fd6223abdbc83e344addcfc93227b8
------------------------>8--------------------
(.text+0x110c): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_wait_until(unsigned int*, unsigned int, bool, std::chrono::duration<long long, std::ratio<1ll, 1ll> >, std::chrono::duration<long long, std::ratio<1ll, 1000000000ll> >)'
collect2: error: ld returned 1 exit status
------------------------>8--------------------
apcupsd: http://autobuild.buildroot.net/results/7a2/7a2cc7a4ac2237c185817f75e55e05d144efd100
------------------------>8--------------------
/tmp/instance-0/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: eh_throw.cc:(.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+0x24): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
collect2: error: ld returned 1 exit status
------------------------>8--------------------
...and many more.
Interesting enough that was not seen earlier because "-matomic"
used to be added in TARGET_{C|CXX}FLAGS via TARGET_ABI,
but later "-matomic" was moved to ARCH_TOOLCHAIN_WRAPPER_OPTS, see
https://git.buildroot.org/buildroot/commit/?id=c568b4f37fa6d7f51e6d14d33d7eb75dfe26d7bf
and since then we started to see that new breakage which we now
attempt to fix right where it hapens on GCC configuration.
In contrast ARC HS family has atomic ops enabled by default thus
we never spotted that kind of problem for it.
More datails with analysis of what really happens under the hodd and
how do error messages above are related to libs of GCC configuration could
be found here: http://lists.busybox.net/pipermail/buildroot/2020-October/293614.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Romain Naour <romain.naour@gmail.com>
[Peter: simplify conditional]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit d2ae7eb2a2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The logic in libbacktrace/configure.ac to detect if __sync builtins
are available assumes they are as soon as target_subdir is not
empty, i.e when cross-compiling. However, some platforms do not have
__sync builtins, so help the configure script a bit.
"libbacktrace_cv_sys_sync=no" is lost when it is added to
HOST_GCC_COMMON_CONF_ENV because the environment is not exported
when executing the libbacktrace configure script.
Use target_configargs to force "libbacktrace_cv_sys_sync=no" when
executiong the libbacktrace configure script.
Fixes:
https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359681
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Romain: use target_configargs="libbacktrace_cv_sys_sync=no"]
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 0bec4c8a4a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
PowerPC has two PLT models: BSS-PLT and Secure-PLT. BSS-PLT uses
runtime code generation to generate the PLT stubs. Secure-PLT was
introduced with GCC 4.1 and Binutils 2.17 (base has GCC 4.2.1 and
Binutils 2.17), and is a more secure PLT format, using a read-only
linkage table, with the dynamic linker populating a non-executable
index table.
References to other distro/BSD transitions:
https://patchwork.openembedded.org/patch/106621/https://reviews.freebsd.org/D20598
Fixes a bug observed when creating SELinux policy where all apps
require execmem because the heap requires execute before this change.
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f9b539bf40)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit dcaf6e75a (package/gcc: pass -Wno-error to debug builds)
introduced non-ASCII characters in a comment, copy-pasted from a
terminal output.
check-package does not like non-ASCII characters, and whines about
them.
Replace the fancy quotes by standard ASCII ones.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2a6003ddd5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc fails to build in debug build with debug optimisations:
BR2_x86_corei7=y
BR2_ENABLE_DEBUG=y
BR2_DEBUG_3=y
BR2_OPTIMIZE_G=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
which fails with:
../../../../libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: ‘st.st_mode’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return S_ISLNK (st.st_mode);
^
Upstream has been unable to reproduce/fix properly, details:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-03/threads.html#00827
Upstream recommends passing -Wno-error as a workaround, see:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519867.html
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr: add the reproducing defconfig]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit dcaf6e75ac)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When building a toolchain with upstream gcc 9.x the build
fail due to several issues.
Note: The upstream Binutils support csky target since
release 2.32 but the support was never enabled in the
Buildroot packaging. So the latest version (2.33.1) was
tested here.
[upstream gcc 9.x w/ glibc csky fork with binutils csky for or binutils 2.33.1]
In file included from <command-line>:
./../include/libc-symbols.h:534:26: error: '__EI___errno_location' specifies less restrictive attributes than its target '__errno_location': 'const', 'nothrow' [-Werror=missing-attributes]
534 | extern __typeof (name) __EI_##name \
[upstream gcc 9.x w/ glibc 2.30 w/ binutils csky fork]
/tmp/ccThLRhb.s: Assembler messages:
/tmp/ccThLRhb.s:10: Error: invalid or unsupported encoding in .cfi_personality
/tmp/ccThLRhb.s:11: Error: invalid or unsupported encoding in .cfi_lsda
[upstream gcc 9.x w/ glibc 2.30 w/ binutils 2.33.1]
build/elf/librtld.os: in function `__sync_fetch_and_add_2':
libgcc/config/csky/linux-atomic.c:116: undefined reference to `__kernel_cmpxchg'
Currenlty, only the toolchain using binutils, gcc, glibc
fork produce a working toolchain. So disable gcc 9.x for
csky.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Guo Ren <guoren@kernel.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 7542a59601)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Remove the old gcc 5.5 fork for or1k architecture
that start to fail to build with recent version
of Binutils >= 2.32 with the following error:
host-gcc-final-or1k-musl-5.4.0-20170218/build/./gcc/crtbeginS.o: addend should be zero for plt relocations
host/or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
https://gitlab.com/kubu93/buildroot/-/jobs/391938988
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that binutils 2.33.1 has been introduced, and we have moved to
2.32 as the default version, it is time to drop support for binutils
2.30.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit bumps ARC toolchain to arc-2019.09-rc1.
We want to test how new toolchain-rc1 builds packages,
so we can make fixes before release of toolcain.
ARC GNU tools of version arc-2019.09-rc1 bring some quite significant changes like:
* Binutils v2_33.20191002 with additional ARC patches
* GCC 9.2.0 with additional ARC patches
* glibc 2.30 with additional ARC patches
Please note that it is a release candidate and it might contain some breakages,
please don't use it for production builds.
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch extends the "copy extra GCC libraries to target" feature to
also work for internal toolchains. The variable has been renamed to be
BR2_TOOLCHAIN_EXTRA_LIBS and the configuration option moved under the
generic toolchain package. For external toolchains, the step that does
the copy is still in the copy_toolchain_lib_root() helper which copies
from the sysroot to the target. For the internal toolchain, the host
gcc-final package does a post install hook to copy the libraries from
the toolchain build folders to both the sysroot and target(!static).
Examples where this can be useful is for adding debug libraries to the
target like the GCC libsanitizer (libasan/liblsan/...).
Cc: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit bumps ARC toolchain to arc-2019.09-eng002. We want to
test how new toolchain-eng002 builds packages, so we can make fixes
before release of toolcain.
Please note that it is an engineering build and it might have all
kinds of breakages, please don't use it for production builds
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Stack pointer adjustment code in xtensa call0 ABI prologue missed a case
of no callee-saved registers and a stack frame size bigger than 128 bytes.
Handle that case.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc 9.1 is around, gcc 8.3 is the default version, so drop
6.5 in order to reduce the gcc choice.
Keep gcc 5.5 since it still used by beaglebone_qt5_defconfig.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libmudflap was removed from gcc 4.9 [1] so it depends on gcc <= 4.9.
This option can't be selected since we removed gcc 4.8 from Buildroot
[2].
[1] 4a692aefee
[2] f66952197b
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As Guo explained, upstream gcc does not support abi-v1 (only abi-v2), but
ck610 needs abi-v1 [0] [1]
To simplify things, we make the whole C-SKY architecture require gcc-9
or later, and add a single exception in gcc to force the ck610 to use
the C-SKY port.
Note that this does not change the default gcc version to be used for
C-SKY: the C-SKY port is still always the default one; the gcc-9 version
is only proposed as an alternative (except for ck610, of course).
[0] http://lists.busybox.net/pipermail/buildroot/2019-July/254386.html
[1] package/Makefile.in#73
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Guo Ren <guoren@kernel.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Romain Naour <romain.naour@gmail.com>
Acked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When storing a TLS symbol to memory, always use an intermediate
register to load it. Otherwise the compiler generates an instruction
which couldn't be encoded and we see:
----------------------------->8---------------------------
In file included from gethstent_r.c:34:
../nss/getXXent_r.c: In function '__gethostent_r':
../nss/getXXent_r.c:168:1: error: unrecognizable insn:
}
^
(insn 25 24 26 5 (set (mem:SI (plus:SI (reg/f:SI 149 virtual-outgoing-args)
(const_int 16 [0x10])) [0 S4 A32])
(plus:SI (reg:SI 25 r25)
(reg:SI 174))) "../nss/getXXent_r.c":160 -1
(nil))
during RTL pass: vregs
../nss/getXXent_r.c:168:1: internal compiler error: in extract_insn, at recog.c:2304
In file included from getnetent_r.c:34:
../nss/getXXent_r.c: In function '__getnetent_r':
../nss/getXXent_r.c:168:1: error: unrecognizable insn:
}
^
(insn 25 24 26 5 (set (mem:SI (plus:SI (reg/f:SI 149 virtual-outgoing-args)
(const_int 16 [0x10])) [0 S4 A32])
(plus:SI (reg:SI 25 r25)
(reg:SI 174))) "../nss/getXXent_r.c":160 -1
(nil))
during RTL pass: vregs
../nss/getXXent_r.c:168:1: internal compiler error: in extract_insn, at recog.c:2304
----------------------------->8---------------------------
Note that this patch is not yet submitted to the GCC's master and
gcc-9-branch but will be submitted soon. That said with th bump of GCC
for ARC this patch will no longer be needed.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Evgeniy Didin <didin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Even if gcc 7 is still maintained for some time (gcc 7.5 is pending),
switch to gcc 8.x since it has been released since 2018-05-02 and
gcc 9.x is available since 2019-05-03.
We have been having toolchains in the autobuilders with gcc
8.x for a while, so the vast majority of the problems should have
already been solved.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
