1. 08 Jan, 2018 1 commit
  2. 07 Sep, 2017 1 commit
  3. 21 Jul, 2017 2 commits
  4. 08 Jul, 2017 1 commit
  5. 04 Jul, 2017 3 commits
  6. 06 Jun, 2017 1 commit
  7. 24 May, 2017 1 commit
  8. 07 May, 2017 1 commit
  9. 01 May, 2017 1 commit
  10. 20 Feb, 2017 1 commit
  11. 09 Feb, 2017 2 commits
  12. 11 Dec, 2016 1 commit
  13. 25 Oct, 2016 1 commit
  14. 12 Sep, 2016 1 commit
  15. 03 Aug, 2016 3 commits
  16. 02 Aug, 2016 1 commit
  17. 25 Jul, 2016 1 commit
  18. 24 Jul, 2016 1 commit
  19. 03 Jul, 2016 2 commits
  20. 27 Jun, 2016 1 commit
  21. 16 May, 2016 1 commit
  22. 27 Apr, 2016 1 commit
    • Thomas Petazzoni's avatar
      gcc: add support for gcc 6 · 519d83bf
      Thomas Petazzoni authored
      This commit adds the support for gcc 6. This release allows to remove
      a large number of our gcc patches, mainly thanks to the Xtensa and
      musl related patches being merged upstream.
      
      Patches kept with no changes:
      
       100-uclibc-conf.patch
       301-missing-execinfo_h.patch
       810-arm-softfloat-libgcc.patch
       830-arm_unbreak_armv4t.patch
       840-microblaze-enable-dwarf-eh-support.patch
       860-cilk-wchar.patch
       890-fix-m68k-compile.patch
      
      Patches dropped because they have been merged upstream, or were
      already upstream backports:
      
       120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
       850-libstdcxx-uclibc-c99.patch (merged in a different form, see
       https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393
      
      )
       870-xtensa-add-mauto-litpools-option.patch (upstream backport)
       871-xtensa-reimplement-register-spilling.patch (upstream backport)
       872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
       873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
       874-xtensa-add-uclinux-support.patch (upstream backport)
       900-libitm-fixes-for-musl-support.patch (upstream backport)
       901-fixincludes-update-for-musl-support.patch (upstream backport)
       902-unwind-fix-for-musl.patch (upstream backport)
       903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
       904-musl-libc-config.patch (upstream backport)
       905-add-musl-support-to-gcc.patch (upstream backport)
       905-add-musl-support-to-gcc.patch (upstream backport)
       906-mips-musl-support.patch (upstream backport)
       907-x86-musl-support.patch (upstream backport)
       908-arm-musl-support.patch (upstream backport)
       909-aarch64-musl-support.patch (upstream backport)
      
      Successfully build-time and run-time tested with
      qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
      configurations.
      
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      519d83bf
  23. 20 Apr, 2016 1 commit
  24. 18 Apr, 2016 1 commit
  25. 20 Mar, 2016 1 commit
    • Thomas Petazzoni's avatar
      toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC · 42735cb9
      Thomas Petazzoni authored
      
      
      Until now, we were assuming that whenever you have gcc 4.8, libatomic
      is available. It turns out that this is not correct, since libatomic
      will not be available if thread support is disabled in the toolchain.
      
      Therefore, __atomic_*() intrinsics may not be available even if the
      toolchain uses gcc 4.8.
      
      To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
      boolean, which indicates whether the toolchain has libatomic. It is
      the case when you are using gcc >= 4.8 *and* thread support is
      enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
      BR2_TOOLCHAIN_HAS_ATOMIC.
      
      As explained in the comment, on certain architectures, libatomic is
      technically not needed to provide the __atomic_*() intrinsics since
      they might be all built-in. However, since libatomic is only absent in
      non-thread capable toolchains, it is not worth making things more
      complex for such seldomly used configuration.
      
      Note that we are introducing the intermediate
      BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
      own for certain packages.
      
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      [Thomas: improve Config.in comment using a suggestion from Yann.]
      42735cb9
  26. 14 Mar, 2016 1 commit
  27. 06 Feb, 2016 1 commit
    • Thomas Petazzoni's avatar
      toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans · 6856e417
      Thomas Petazzoni authored
      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: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      6856e417
  28. 30 Jan, 2016 1 commit
    • Thomas Petazzoni's avatar
      package, toolchain: remove BR2_TOOLCHAIN_HAS_GCC_BUG_* options · 07bb65c6
      Thomas Petazzoni authored
      
      
      Quite some time ago, we added the options
      BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to
      indicate if the toolchain was affected by those gcc bugs, which were
      causing build failure with a number of packages.
      
      With the recent change in the external toolchain logic to provide only
      the latest version of each toolchain "family", all the toolchains
      which were affected by those issues disappeared from Buildroot. Those
      options are no longer being selected anywhere, and being blind
      options, it means their value is always going to be "disabled".
      
      Conquently, this commit removes those options completely, and updates
      all the packages where they were used.
      
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      07bb65c6
  29. 11 Jan, 2016 1 commit
  30. 02 Nov, 2015 1 commit
  31. 01 Sep, 2015 1 commit
  32. 05 Aug, 2015 1 commit
  33. 22 Jun, 2015 1 commit