2010-07-28 00:08:16 +02:00
|
|
|
# Generic toolchain options
|
|
|
|
|
|
|
|
|
|
# we want gdb config in the middle of both source and external
|
|
|
|
|
# toolchains, but mconf won't let us source the same file twice,
|
|
|
|
|
# so put it here instead
|
gdb: convert to the package infrastructure
This commit converts gdb to the package infrastructure, and therefore
moves it from toolchain/gdb to package/gdb.
The target package is now visible in "Package selection for the
target" => "Debugging, profiling and benchmark". The main option,
"gdb", forcefully selects the "gdbserver" sub-option by
default. Another sub-option, "full debugger" allows to install the
complete gdb on the target. When this option is enabled, then
"gdbserver" is no longer forcefully selected. This ensures that at
least gdbserver or the full debugger gets built/installed, so that the
package is not a no-op.
The host debugger is still enabled through a configuration option in
"Toolchain". It is now visible regardless of the toolchain type (it
used to be hidden for External Toolchains). The configuration options
relative to the host debugger are now in package/gdb/Config.in.host,
similar to how we have package/binutils/Config.in.host.
Since gdb is now a proper package, it is no longer allowed to 'select
BR2_PTHREADS_DEBUG' to ensure thread debugging is available when
needed. Instead, it now 'depends on
BR2_TOOLCHAIN_HAS_THREADS_DEBUG'. This option, in turn, is selected by
the different toolchain backends when appropriate. The
'BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED' option is removed, since
we no longer need to know when it is allowed to 'select
BR2_PTHREADS_DEBUG'. Also, the 'BR2_PTHREADS_DEBUG' option is moved to
appear right below the thread implementation selection (in the case of
the Buildroot toolchain backend).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-07 02:04:33 +02:00
|
|
|
source "package/gdb/Config.in.host"
|
2010-07-28 00:08:16 +02:00
|
|
|
|
2016-02-20 13:42:46 +01:00
|
|
|
# https://sourceware.org/bugzilla/show_bug.cgi?id=19405
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405
|
|
|
|
|
bool
|
|
|
|
|
|
2012-11-03 18:47:49 +01:00
|
|
|
config BR2_TOOLCHAIN_HAS_NATIVE_RPC
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-13 17:27:37 +01:00
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_USE_WCHAR
|
|
|
|
|
bool
|
2009-01-30 17:28:26 +01:00
|
|
|
|
|
|
|
|
config BR2_ENABLE_LOCALE
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-13 17:27:37 +01:00
|
|
|
bool
|
|
|
|
|
|
2010-12-13 17:27:41 +01:00
|
|
|
config BR2_INSTALL_LIBSTDCPP
|
|
|
|
|
bool
|
|
|
|
|
|
2010-12-13 17:27:44 +01:00
|
|
|
config BR2_TOOLCHAIN_HAS_THREADS
|
|
|
|
|
bool
|
|
|
|
|
|
2011-11-24 14:26:52 +01:00
|
|
|
config BR2_TOOLCHAIN_HAS_THREADS_DEBUG
|
|
|
|
|
bool
|
|
|
|
|
|
2014-02-18 22:08:59 +01:00
|
|
|
config BR2_TOOLCHAIN_HAS_THREADS_NPTL
|
|
|
|
|
bool
|
|
|
|
|
|
2011-05-30 23:56:57 +02:00
|
|
|
config BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
|
|
|
|
|
bool
|
|
|
|
|
|
2013-09-02 18:06:36 +02:00
|
|
|
config BR2_TOOLCHAIN_HAS_SSP
|
|
|
|
|
bool
|
|
|
|
|
|
2009-04-06 11:21:26 +02:00
|
|
|
config BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
bool "Purge unwanted locales"
|
|
|
|
|
help
|
|
|
|
|
Explicitly specify what locales to install on target. If N
|
|
|
|
|
then all locales supported by packages are installed.
|
|
|
|
|
|
|
|
|
|
config BR2_ENABLE_LOCALE_WHITELIST
|
|
|
|
|
string "Locales to keep"
|
|
|
|
|
default "C en_US de fr"
|
|
|
|
|
depends on BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
help
|
|
|
|
|
Whitespace seperated list of locales to allow on target.
|
|
|
|
|
Locales not listed here will be removed from the target.
|
|
|
|
|
See 'locale -a' on your host for a list of locales available
|
|
|
|
|
on your build host, or have a look in /usr/share/locale in
|
|
|
|
|
the target file system for available locales.
|
|
|
|
|
|
|
|
|
|
Notice that listing a locale here doesn't guarantee that it
|
|
|
|
|
will be available on the target - That purely depends on the
|
|
|
|
|
support for that locale in the selected packages.
|
|
|
|
|
|
Add support to generate locale data
In order to use locale support on a Linux system, you need locale data
to be present:
* on a (e)glibc based system, this data is typically in the
/usr/lib/locale/locale-archive file, which can be created and
extended using the localedef program
* on an uClibc based system, the set of supported locales is defined
at build time by an uClibc configuration option.
This patch implements generating locale data for the following cases:
* Internal toolchain
* External toolchain based on (e)glibc. uClibc external toolchains
are not supported, because with uClibc, the set of supported
locales is defined at build time. CodeSourcery and Linaro
toolchains have been tested, Crosstool-NG toolchains are believed
to work properly as well.
* Toolchains built using the Crosstool-NG backend, but only (e)glibc
toolchains.
This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.
Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-08 06:39:22 +02:00
|
|
|
config BR2_GENERATE_LOCALE
|
|
|
|
|
string "Generate locale data"
|
|
|
|
|
default ""
|
|
|
|
|
depends on \
|
2014-11-13 23:17:26 +01:00
|
|
|
(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && BR2_ENABLE_LOCALE) || \
|
2013-06-30 21:29:09 +02:00
|
|
|
BR2_TOOLCHAIN_USES_GLIBC
|
Add support to generate locale data
In order to use locale support on a Linux system, you need locale data
to be present:
* on a (e)glibc based system, this data is typically in the
/usr/lib/locale/locale-archive file, which can be created and
extended using the localedef program
* on an uClibc based system, the set of supported locales is defined
at build time by an uClibc configuration option.
This patch implements generating locale data for the following cases:
* Internal toolchain
* External toolchain based on (e)glibc. uClibc external toolchains
are not supported, because with uClibc, the set of supported
locales is defined at build time. CodeSourcery and Linaro
toolchains have been tested, Crosstool-NG toolchains are believed
to work properly as well.
* Toolchains built using the Crosstool-NG backend, but only (e)glibc
toolchains.
This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.
Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-08 06:39:22 +02:00
|
|
|
help
|
|
|
|
|
Generate support for a list of locales. Locales can be
|
|
|
|
|
specified with or without encoding, when no encoding is
|
|
|
|
|
specified, UTF-8 is assumed. Examples of locales: en_US,
|
|
|
|
|
fr_FR.UTF-8.
|
|
|
|
|
|
2014-07-27 21:28:32 +02:00
|
|
|
config BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_COPY
|
|
|
|
|
bool "Copy gconv libraries"
|
|
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC
|
|
|
|
|
help
|
|
|
|
|
The gconv libraries are used to convert between different
|
|
|
|
|
character sets (charsets).
|
|
|
|
|
|
|
|
|
|
Say 'y' if you need to store and/or display different charsets.
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_LIST
|
|
|
|
|
string "Gconv libraries to copy"
|
|
|
|
|
depends on BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_COPY
|
|
|
|
|
help
|
|
|
|
|
Set to the list of gconv libraries to copy.
|
|
|
|
|
Leave empty to copy all gconv libraries.
|
|
|
|
|
|
|
|
|
|
Specify only the basename of the libraries, leave
|
|
|
|
|
out the .so extension. Eg.:
|
|
|
|
|
IBM850 ISO8859-15 UNICODE
|
|
|
|
|
|
|
|
|
|
Note: the full set of gconv libs are ~8MiB (on ARM).
|
|
|
|
|
|
2010-05-24 21:17:50 +02:00
|
|
|
# glibc and eglibc directly include gettext, so a separatly compiled
|
|
|
|
|
# gettext isn't needed and shouldn't be built to avoid conflicts. Some
|
|
|
|
|
# packages always need gettext, other packages only need gettext when
|
|
|
|
|
# locale support is enabled. See the documentation for how packages
|
|
|
|
|
# should rely on the following two options.
|
|
|
|
|
|
Add a BR2_NEEDS_GETTEXT option
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-05-13 22:21:08 +02:00
|
|
|
config BR2_NEEDS_GETTEXT
|
|
|
|
|
bool
|
2013-06-30 21:29:09 +02:00
|
|
|
default y if BR2_TOOLCHAIN_USES_UCLIBC
|
2010-05-24 21:17:50 +02:00
|
|
|
|
|
|
|
|
config BR2_NEEDS_GETTEXT_IF_LOCALE
|
|
|
|
|
bool
|
|
|
|
|
default y if (BR2_NEEDS_GETTEXT && BR2_ENABLE_LOCALE)
|
Add a BR2_NEEDS_GETTEXT option
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-05-13 22:21:08 +02:00
|
|
|
|
2011-01-10 15:28:41 +01:00
|
|
|
config BR2_USE_MMU
|
2015-06-04 00:34:03 +02:00
|
|
|
bool "Enable MMU support" if BR2_ARCH_HAS_MMU_OPTIONAL
|
|
|
|
|
default y if BR2_ARCH_HAS_MMU_OPTIONAL || BR2_ARCH_HAS_MMU_MANDATORY
|
2011-01-10 15:28:41 +01:00
|
|
|
help
|
|
|
|
|
If your target has a MMU, you should say Y here. If you
|
|
|
|
|
are unsure, just say Y.
|
|
|
|
|
|
2009-01-30 17:28:26 +01:00
|
|
|
config BR2_TARGET_OPTIMIZATION
|
|
|
|
|
string "Target Optimizations"
|
2014-12-21 14:00:25 +01:00
|
|
|
default ""
|
2009-01-30 17:28:26 +01:00
|
|
|
help
|
|
|
|
|
Optimizations to use when building for the target host.
|
2010-06-14 14:36:04 +02:00
|
|
|
NOTE: gcc optimization level is defined in build options.
|
2011-06-23 11:21:21 +02:00
|
|
|
|
|
|
|
|
config BR2_TARGET_LDFLAGS
|
|
|
|
|
string "Target linker options"
|
|
|
|
|
help
|
2012-01-13 20:23:23 +01:00
|
|
|
Extra options to pass to the linker when building for the target.
|
2013-01-13 05:52:13 +01:00
|
|
|
|
toolchain: linker options with a $ sign are not supported
As reported in bug #7172 [0], setting BR2_TARGET_LDFLAGS to a value
containing a $ sign can lead to unexpected results.
This is because it is very hard to know when the $ sign gets evaluated:
- in the Buildroot-level make
- in the shell called by the Buildroot-level make
- in the package's own build-system, either at configure time, in the
Makefile, in a shell in the Makefile...
So, it is very difficult to know how much escaping that would need.
A proposal is to use a shell variable to pass such values unmolested.
But it is not that simple either, since it still contains a $ sign, and
there is not much certainty as to when it would be evaluated.
Instead, just document this limitation, both in the help text for
BR2_TARGET_LDFLAGS, and in the known-issues section in the manual.
Does not really fix #7172, but at least the limitation is documented.
[0] https://bugs.buildroot.org/show_bug.cgi?id=7172
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Mike Zick <minimod@morethan.org>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-31 00:57:15 +02:00
|
|
|
Note that options with a '$' sign (eg. -Wl,-rpath='$ORIGIN/../lib')
|
|
|
|
|
are not supported.
|
|
|
|
|
|
2013-01-13 05:52:13 +01:00
|
|
|
config BR2_ECLIPSE_REGISTER
|
|
|
|
|
bool "Register toolchain within Eclipse Buildroot plug-in"
|
|
|
|
|
help
|
|
|
|
|
This options tells Buildroot to generate the necessary
|
|
|
|
|
configuration files to make your toolchain appear within
|
|
|
|
|
Eclipse, through the Eclipse Buildroot plugin.
|
2014-03-01 15:52:57 +01:00
|
|
|
|
|
|
|
|
# Options for packages to depend on, if they require at least a
|
|
|
|
|
# specific version of the kernel headers.
|
|
|
|
|
# Toolchains should choose the adequate option (ie. the highest
|
|
|
|
|
# version, not all of them).
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_3
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_3
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_5
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_6
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_5
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_6
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_9
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_9
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_13
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
|
2014-03-01 15:53:01 +01:00
|
|
|
|
2014-04-01 11:19:48 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_13
|
|
|
|
|
|
2014-06-09 13:30:33 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
|
|
|
|
|
|
2014-08-04 04:29:22 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_16
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15
|
|
|
|
|
|
2014-10-06 13:44:39 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_16
|
|
|
|
|
|
2014-12-08 12:10:39 +01:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17
|
|
|
|
|
|
2015-02-09 13:31:23 +01:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
|
|
|
|
|
|
2015-04-13 15:00:23 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
|
|
|
|
|
|
2015-06-22 15:11:03 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
|
|
|
|
|
|
2015-09-01 10:05:20 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
|
|
|
|
|
|
2015-11-02 15:56:51 +01:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
|
|
|
|
|
|
2016-01-11 11:52:36 +01:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
|
|
|
|
|
|
2016-03-14 11:14:10 +01:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
|
|
|
|
|
|
2016-05-16 13:58:12 +02:00
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_6
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
|
|
|
|
|
|
2014-03-01 15:53:01 +01:00
|
|
|
# This order guarantees that the highest version is set, as kconfig
|
|
|
|
|
# stops affecting a value on the first matching default.
|
|
|
|
|
config BR2_TOOLCHAIN_HEADERS_AT_LEAST
|
|
|
|
|
string
|
2016-05-16 13:58:12 +02:00
|
|
|
default "4.6" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_6
|
2016-03-14 11:14:10 +01:00
|
|
|
default "4.5" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
|
2016-01-11 11:52:36 +01:00
|
|
|
default "4.4" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
|
2015-11-02 15:56:51 +01:00
|
|
|
default "4.3" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
|
2015-09-01 10:05:20 +02:00
|
|
|
default "4.2" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
|
2015-06-22 15:11:03 +02:00
|
|
|
default "4.1" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
|
2015-04-13 15:00:23 +02:00
|
|
|
default "4.0" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
|
2015-02-09 13:31:23 +01:00
|
|
|
default "3.19" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
|
2014-12-08 12:10:39 +01:00
|
|
|
default "3.18" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
|
2014-10-06 13:44:39 +02:00
|
|
|
default "3.17" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17
|
2014-08-04 04:29:22 +02:00
|
|
|
default "3.16" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_16
|
2014-06-09 13:30:33 +02:00
|
|
|
default "3.15" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15
|
2014-04-01 11:19:48 +02:00
|
|
|
default "3.14" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
|
2014-03-01 15:53:01 +01:00
|
|
|
default "3.13" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_13
|
|
|
|
|
default "3.12" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
|
|
|
|
|
default "3.11" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
|
|
|
|
|
default "3.10" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
|
|
|
|
|
default "3.9" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_9
|
|
|
|
|
default "3.8" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
|
|
|
|
|
default "3.7" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
|
|
|
|
|
default "3.6" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_6
|
|
|
|
|
default "3.5" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_5
|
|
|
|
|
default "3.4" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
|
|
|
|
|
default "3.3" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_3
|
|
|
|
|
default "3.2" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
|
|
|
|
|
default "3.1" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
|
|
|
|
|
default "3.0" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
|
|
|
|
|
default "2.6"
|
2015-08-04 20:00:33 +02:00
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_3
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_4
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_3
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_4
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_6
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_6
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_5
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
|
|
|
|
|
|
2016-04-27 15:54:03 +02:00
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST_6
|
|
|
|
|
bool
|
|
|
|
|
select BR2_TOOLCHAIN_GCC_AT_LEAST_5
|
|
|
|
|
|
2015-08-04 20:00:33 +02:00
|
|
|
# This order guarantees that the highest version is set, as kconfig
|
|
|
|
|
# stops affecting a value on the first matching default.
|
|
|
|
|
config BR2_TOOLCHAIN_GCC_AT_LEAST
|
|
|
|
|
string
|
2016-04-27 15:54:03 +02:00
|
|
|
default "6" if BR2_TOOLCHAIN_GCC_AT_LEAST_6
|
2015-08-04 20:00:33 +02:00
|
|
|
default "5" if BR2_TOOLCHAIN_GCC_AT_LEAST_5
|
|
|
|
|
default "4.9" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
|
|
|
|
|
default "4.8" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
|
|
|
|
|
default "4.7" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
|
|
|
|
|
default "4.6" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_6
|
|
|
|
|
default "4.5" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
|
|
|
|
|
default "4.4" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_4
|
|
|
|
|
default "4.3" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_3
|
toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
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 <thomas.petazzoni@free-electrons.com>
2016-02-02 16:31:20 +01:00
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_SYNC_1
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on !BR2_bfin
|
|
|
|
|
depends on !BR2_microblaze
|
|
|
|
|
depends on !BR2_sparc
|
|
|
|
|
depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT)
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_SYNC_2
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_TOOLCHAIN_HAS_SYNC_1
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_SYNC_4
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on !BR2_sparc
|
|
|
|
|
depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT)
|
|
|
|
|
|
|
|
|
|
# The availability of __sync for 8-byte types on ARM is somewhat
|
|
|
|
|
# complicated:
|
|
|
|
|
#
|
|
|
|
|
# - It appeared in gcc starting with gcc 4.7.
|
|
|
|
|
#
|
|
|
|
|
# - On ARMv7, there is no problem, it can be directly implemented in
|
|
|
|
|
# userspace.
|
|
|
|
|
#
|
|
|
|
|
# - On < ARMv7, it requires help from the kernel. Unfortunately, the
|
|
|
|
|
# libgcc code implementing 8-byte __sync with the help from the
|
|
|
|
|
# kernel calls __write() when a failure occurs, which is a function
|
|
|
|
|
# internal to glibc, not available in uClibc and musl. This means
|
|
|
|
|
# that the 8-byte __sync operations are not available on < ARMv7
|
|
|
|
|
# with uClibc and musl. This problem was fixed as part of gcc
|
|
|
|
|
# PR68059, which was backported to the gcc 5 branch, but isn't yet
|
|
|
|
|
# part of any gcc 5.x release.
|
|
|
|
|
#
|
|
|
|
|
config BR2_TOOLCHAIN_ARM_HAS_SYNC_8
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on BR2_arm || BR2_armeb
|
|
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
|
|
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_ARM_CPU_ARMV7A
|
|
|
|
|
|
|
|
|
|
# 8-byte intrinsics available on most x86 CPUs, except a few old ones
|
|
|
|
|
config BR2_TOOLCHAIN_X86_HAS_SYNC_8
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on BR2_i386
|
|
|
|
|
depends on !BR2_x86_i486
|
|
|
|
|
depends on !BR2_x86_c3
|
|
|
|
|
depends on !BR2_x86_winchip_c6
|
|
|
|
|
depends on !BR2_x86_winchip2
|
|
|
|
|
|
|
|
|
|
# 8-byte intrinsics available:
|
|
|
|
|
# - On all 64 bits architecture
|
|
|
|
|
# - On a certain combinations of ARM platforms
|
|
|
|
|
# - On certain x86 32 bits CPUs
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_SYNC_8
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_ARCH_IS_64
|
|
|
|
|
default y if BR2_TOOLCHAIN_ARM_HAS_SYNC_8
|
|
|
|
|
default y if BR2_TOOLCHAIN_X86_HAS_SYNC_8
|
|
|
|
|
|
toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-06 21:47:16 +01:00
|
|
|
# libatomic is available since gcc 4.8, when thread support is
|
|
|
|
|
# enabled.
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_LIBATOMIC
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
|
|
|
|
|
BR2_TOOLCHAIN_HAS_THREADS
|
|
|
|
|
|
toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
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 <thomas.petazzoni@free-electrons.com>
2016-02-02 16:31:20 +01:00
|
|
|
# __atomic intrinsics are available:
|
|
|
|
|
# - with gcc 4.8, either through built-ins or libatomic, on all
|
toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-06 21:47:16 +01:00
|
|
|
# architectures. Since we don't want to separate the cases where
|
|
|
|
|
# libatomic is needed vs. not needed, we simplify thing and only
|
|
|
|
|
# support situations where libatomic is available, even if on some
|
|
|
|
|
# architectures libatomic is not strictly needed as all __atomic
|
|
|
|
|
# intrinsics might be built-in. The only case where libatomic is
|
|
|
|
|
# missing entirely is when the toolchain does not have support for
|
|
|
|
|
# threads. However, a package that does not need threads but still
|
|
|
|
|
# uses atomics is quite a corner case, which does not warrant the
|
|
|
|
|
# added complexity.
|
toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
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 <thomas.petazzoni@free-electrons.com>
2016-02-02 16:31:20 +01:00
|
|
|
# - with gcc 4.7, libatomic did not exist, so only built-ins are
|
|
|
|
|
# available. This means that __atomic can only be used in a subset
|
|
|
|
|
# of the architectures
|
|
|
|
|
config BR2_TOOLCHAIN_HAS_ATOMIC
|
|
|
|
|
bool
|
toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-06 21:47:16 +01:00
|
|
|
default y if BR2_TOOLCHAIN_HAS_LIBATOMIC
|
toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
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 <thomas.petazzoni@free-electrons.com>
2016-02-02 16:31:20 +01:00
|
|
|
default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 && BR2_arm
|
|
|
|
|
default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 && BR2_armeb
|
|
|
|
|
default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 && BR2_xtensa
|
|
|
|
|
default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 && BR2_ARCH_IS_64
|
