Skip to content
GitLab
  1. 25 Oct, 2016 1 commit
  3. 12 Sep, 2016 1 commit
  5. 03 Aug, 2016 3 commits
  7. 02 Aug, 2016 1 commit
  9. 25 Jul, 2016 1 commit
  11. 24 Jul, 2016 1 commit
  13. 03 Jul, 2016 2 commits
  15. 27 Jun, 2016 1 commit
  17. 16 May, 2016 1 commit
  19. 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
  21. 20 Apr, 2016 1 commit
  23. 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
  27. 14 Mar, 2016 1 commit
  29. 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
  31. 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
  33. 11 Jan, 2016 1 commit
  35. 02 Nov, 2015 1 commit
  37. 01 Sep, 2015 1 commit
  39. 05 Aug, 2015 1 commit
  41. 22 Jun, 2015 1 commit
  43. 09 Jun, 2015 1 commit
  45. 22 Apr, 2015 2 commits
  47. 13 Apr, 2015 1 commit
  49. 01 Apr, 2015 2 commits
  51. 09 Feb, 2015 1 commit
  53. 21 Dec, 2014 1 commit
    • Yann E. MORIN's avatar
      toolchain: get rid of -pipe from optimisations · 01c34b38
      Yann E. MORIN authored 
      

-pipe is causing some build failures in Linux kernel >= 3.17.

Also, nowadays, using -pipe does not gain as much as it used to back in
the days:

Measurements made with a 3.16.7 Linux kernel:
    make linux-depends
    time sh -c 'make linux-build >/dev/null 2>&1'

Without -pipe:
    716.32user 54.44system 3:42.12elapsed 346%CPU
    721.22user 54.47system 3:41.81elapsed 349%CPU
    722.44user 54.00system 3:42.13elapsed 349%CPU
    721.03user 53.81system 3:41.92elapsed 349%CPU
    713.21user 53.63system 3:40.51elapsed 347%CPU
    706.67user 52.42system 3:38.40elapsed 347%CPU
    714.40user 53.18system 3:40.16elapsed 348%CPU
    706.01user 53.09system 3:37.87elapsed 348%CPU
    705.98user 53.01system 3:38.03elapsed 348%CPU
    714.17user 53.55system 3:39.98elapsed 348%CPU
Average:                   3:40.29elapsed

With -pipe:
    720.13user 53.90system 3:41.98elapsed 348%CPU
    713.38user 53.69system 3:40.44elapsed 347%CPU
    711.60user 52.81system 3:39.06elapsed 348%CPU
    708.66user 53.09system 3:38.59elapsed 348%CPU
    711.76user 53.00system 3:38.48elapsed 350%CPU
    717.85user 53.97system 3:41.77elapsed 348%CPU
    716.77user 53.77system 3:40.91elapsed 348%CPU
    717.48user 53.65system 3:41.24elapsed 348%CPU
    721.44user 55.67system 3:43.45elapsed 347%CPU
    724.61user 55.63system 3:43.35elapsed 349%CPU
Average:                   3:40.93elapsed

The delta is well in the measurement noise.

Just get rid of it.

Signed-off-by: default avatar"Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      01c34b38
  55. 08 Dec, 2014 1 commit
  57. 21 Nov, 2014 2 commits
  59. 06 Oct, 2014 1 commit
  61. 18 Aug, 2014 2 commits
  63. 04 Aug, 2014 1 commit
  65. 03 Aug, 2014 1 commit
    • Anton Kolesov's avatar
      toolchain: Add config option for atomic intrinsics · cbffd505
      Anton Kolesov authored 
      

GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.

Signed-off-by: default avatarAnton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      cbffd505