buildroot/toolchain, branch 2016.02

toolchain-external/Config.in: Fix Linaro typo

2016-02-21T21:19:54+00:00

Signed-off-by: Peter Korsgaard

toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans

2016-02-06T10:16:00+00:00

Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option to indicate whether the architecture supports atomic operations or not. However, the reality of atomic operations support is much more complicated and requires more than one option to be expressed properly. There are in fact two types of atomic built-ins provided by gcc: (1) The __sync_*() family of functions, which have been in gcc for a long time (probably gcc 4.1). They are available in variants operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some architectures implement a number of variants, some do not implement any, some implement all of them. They are now considered "legacy" by the gcc developers but are nonetheless still being used by a significant number of userspace libraries and applications. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html (2) The __atomic_*() family of functions, which have been introduced in gcc 4.7. They have been introduced in order to support C++11 atomic operations. In gcc 4.8, they are available on all architectures, either built-in or in the libatomic library part of the gcc runtime (in which case the application needs to be linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics are only supported on certain architectures, since libatomic did not exist at the time. For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because depending on the architecture, some variants may or may not be available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the variant is missing would cause a large number of packages to become unavailable, even if they in fact use only more common variants available on a large number of architectures. For this reason, we've chosen to introduce four new Config.in options: - BR2_TOOLCHAIN_HAS_SYNC_1 - BR2_TOOLCHAIN_HAS_SYNC_2 - BR2_TOOLCHAIN_HAS_SYNC_3 - BR2_TOOLCHAIN_HAS_SYNC_4 Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte and 8-byte __sync_*() built-ins respectively. For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if the __atomic_*() built-ins are available. Note that it is up to the package to link with -latomic when gcc is >= 4.8. Since __atomic_*() intrinsics for all sizes are supported starting We conducted a fairly large analysis about various architectures supported by Buildroot, as well as with a number of different toolchains, to check which combinations support which variant. To do, we linked the following program with various toolchains: int main(void) { uint8_t a; uint16_t b; uint32_t c; uint64_t d; __sync_fetch_and_add(&a, 3); __sync_fetch_and_add(&b, 3); __sync_fetch_and_add(&c, 3); __sync_fetch_and_add(&d, 3); __sync_val_compare_and_swap(&a, 1, 2); __sync_val_compare_and_swap(&b, 1, 2); __sync_val_compare_and_swap(&c, 1, 2); __sync_val_compare_and_swap(&d, 1, 2); __atomic_add_fetch(&a, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&b, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&c, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&d, 3, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); return 0; } And looked at which symbols were unresolved. For the __atomic_*() ones, we tested with and without -latomic to see which variants are built-in, which variants require libatomic. This testing effort has led to the following results: __sync __atomic gcc 1 2 4 8 1 2 4 8 ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT] ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT] ARM Y Y Y X Y Y Y Y 4.8, 4.7 ARM Y Y Y - 4.5 AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1 Bfin - - Y - 4.3 i386 (i386) - - - - L L L L 4.9 i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6] i386 (> i586) Y Y Y Y L L L L 4.9 Microblaze - - Y - L L Y L 4.9 MIPS Y Y Y - Y Y Y L 4.9 MIPS64 Y Y Y Y Y Y Y Y 4.9 NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2 PowerPC Y Y Y - Y Y Y L 4.9 SuperH Y Y Y - Y Y Y L 4.9 SPARC - - - - L L L L 4.9 SPARC64 Y Y Y Y Y Y Y Y 4.9 x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9 Xtensa Y Y Y - Y Y Y Y 4.9 Notes: * __atomic built-ins appeared in gcc 4.7, so for toolchais older than that, the __atomic column is empty. * Y means 'supported built-in' * L means 'supported via linking to libatomic' (only for __atomic functions) * X indicates a very special case for 8 bytes __sync built-ins on ARM. On ARMv7, there is no problem, starting from gcc 4.7, the __sync built-in for 8 bytes integers is implemented, fully in userspace. For cores < ARMv7, doing a 8 bytes atomic operation requires help from the kernel. Unfortunately, the libgcc code implementing this uses the __write() function to display an error, and this function is internal to glibc. Therefore, if you're using glibc everything is fine, but if you're using uClibc or musl, you cannot link an application that uses 8 bytes __sync operations. This has been fixed as part of gcc PR68095, merged in the gcc 5 branch but not yet part of any gcc release. * - means not supported This commit only introduces the new options. Follow-up commits will progressively change the packages using BR2_ARCH_HAS_ATOMICS to use the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC until the point where BR2_ARCH_HAS_ATOMICS can be removed. Signed-off-by: Thomas Petazzoni

toolchain/external: newer Linaro toolchains do not provide source code

2016-02-03T22:46:27+00:00

Currently, we have a pattern-matching that automatically derives the the source tarball filename from the binary tarball filename. However, the latest Linaro toolchains no longer follow that scheme (and do not even readily provide the sources...). Remove the generic pattern-matching, and explicitly set the source tarball name for those toolchains that do have a source tarball readily available. Signed-off-by: "Yann E. MORIN" Cc: Romain Naour Signed-off-by: Thomas Petazzoni

toolchain: copy_toolchain_lib_root: rename LIBSPATH to LIBPATHS

2016-02-03T22:46:00+00:00

LIBSPATH is populated based on a find with a pattern that can look like: libfoo*.so and thus the output of the find will contain all file paths that match this pattern. Unfortunately, the name LIBSPATH suggests that only one entry is returned, rather than possibly multiple. As this code is quite complex, use the more accurate name LIBPATHS iso LIBSPATH. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

toolchain-external: bump Linaro ARMEB to 2015.11-2

2016-02-01T18:38:02+00:00

Signed-off-by: Romain Naour [Thomas: only add the symlink with the old 2014.09 Linaro toolchain, for the newer ones, it is no longer needed.] Signed-off-by: Thomas Petazzoni

toolchain-external: bump Linaro ARM to 2015.11-2

2016-02-01T18:38:02+00:00

Runtime tested with Qemu 2.3.1 using a configuration based on qemu_arm_vexpress_defconfig with BR2_ARM_ENABLE_VFP and BR2_ARM_EABIHF selected Signed-off-by: Romain Naour [Thomas: only add the symlink with the old 2014.09 Linaro toolchain, for the newer ones, it is no longer needed. This has been runtime tested in Qemu.] Signed-off-by: Thomas Petazzoni

toolchain-external: bump Linaro AArch64 to 2015.11-2

2016-02-01T18:27:29+00:00

Runtime tested with Qemu 2.3.1 using qemu_aarch64_virt_defconfig. Signed-off-by: Romain Naour [Thomas: only add the symlink with the old 2014.09 Linaro toolchain, for the newer ones, it is no longer needed. This has been runtime tested in Qemu.] Signed-off-by: Thomas Petazzoni

toolchain-external: create symlink ARCH_LIB_DIR->lib

2016-02-01T13:20:10+00:00

Currently, following symbolic links are created in both target and staging directories: - lib(32|64) --> lib - usr/lib(32|64) --> lib The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64). In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for lib64-fp in case of ABI=n64) More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib. However, feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these links must be kept. Fix the problem as follows: - For internal toolchains: no change - For external toolchains: create a symlink ARCH_LIB_DIR->lib if (usr/)ARCH_LIB_DIR does not exist yet. Signed-off-by: Thomas De Schampheleire Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: "Yann E. Morin" Cc: Romain Naour Cc: Peter Korsgaard Reviewed-by: Romain Naour Tested-by: Romain Naour Signed-off-by: Thomas Petazzoni

toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64

2016-02-01T13:20:05+00:00

The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an rsync of various directories from the extracted external toolchain to the corresponding directory in staging. The relevant (simplified) snippet is: for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \ rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \ --exclude '/lib/' --exclude '/lib32/' \ --exclude '/lib64/' \ $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \ done ; \ The exclusion logic of lib/lib32/lib64 has originally been added by commit 5628776c4a4d29d0715633ea463b64cc19e19c5a with the purpose of only copying the relevant usr/lib* directory from the toolchain to staging, instead of all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be copied and usr/lib and usr/lib32 are ignored. It works by ignoring any lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have impact on the files beneath the main source directory.) However, ARCH_LIB_DIR can take other values than (lib, lib32, lib64), for example lib32-fp or lib64-fp (Octeon III toolchain with -march=octeon3). In the existing code, the rsync for 'usr' would then already copy these lib directories, and the next rsync for 'usr/$${ARCH_LIB_DIR}' does nothing. By itself, this is not a very big problem: the staging directory simply has some extra directories. However, a subsequent patch will create a staging symlink from $${ARCH_LIB_DIR} to lib. The first rsync would then overwrite that symlink with the real directory usr/$${ARCH_LIB_DIR} from the toolchain, which is not correct. Assuming the patch that creates the symlink ARCH_LIB_DIR->lib is applied, the original situation after 'make clean toolchain' with an ARCH_LIB_DIR=lib32-fp is: $ ls -ld output/staging/{,usr/}lib* output/target/{usr/,}lib* drwxr-xr-x 2 4096 May 26 2015 output/staging/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 13:47 output/staging/usr/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/usr/lib32 -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib32-fp drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib64-fp drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32 drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp drwxr-xr-x 2 4096 Jan 20 13:48 output/target/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 13:48 output/target/usr/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32-fp -> lib Notice how usr/lib32-fp is not a symlink but a directory, and the presence of an unnecessary directory usr/lib64-fp. This patch improves the rsync exclusion rules by excluding any lib* directory on the first rsync. As this would also exclude any libexec/libexec32/... directory, explicitly include them first (first match takes precedence). This (as is already the case today) results in more usr/libexec* directories than needed, but it is not touched by this patch. With the fix applied, the situation becomes: drwxr-xr-x 2 4096 May 26 2015 output/staging/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32-fp -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32-fp -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32 drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp drwxr-xr-x 2 4096 Jan 20 14:27 output/target/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 14:27 output/target/usr/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32-fp -> lib For cases where ARCH_LIB_DIR is one of lib, lib32 or lib64 this fix makes no difference, and likewise for internal toolchains. Signed-off-by: Thomas De Schampheleire Cc: Samuel Martin Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Reviewed-by: Romain Naour Signed-off-by: Thomas Petazzoni

toolchain-external: don't exclude too much lib in sysroot rsync

2016-02-01T13:19:34+00:00