For each compiler, also set a CMAKE_GCOV var referencing the appropriate
gcov tool.
Tested with gcc and host-gcc on the ChromeOS codebase.
Signed-off-by: Jeremy Bettis <jbettis@chromium.org>
The host toolchain makes use of the host toolchain libraries (i.e.
`-nostdlib` is not specified), so it is not necessary to detect the
toolchain libgcc path and specify one manually.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates the build system to always detect the libgcc path
for the host platforms regardless of the target architecture.
The native_posix_64 target previously used the x32 ABI (`-mx32`) and
the multilib for this ABI was not commonly available in the x86-64 host
toolchains.
That is no longer the case because native_posix_64 had been updated to
use the x86-64 ABI (`-m64`).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Fix an issue with 'ZEPHYR_TOOLCHAIN_VARIANT=host' where CMAKE_C_FLAGS
was incorrectly assumed to be set.
This fixes#21614
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Since x86_64-zephyr-elf is a multi-lib toolchain, m32/m64
need to be specified for the compiler to return the correct
library path when queried (e.g. --print-libgcc-file-name).
This affects the compile check done by CMake. Without these
flags, the compiler returns incorrect toolchain path (e.g.
requiring 64-bit libraries but returning 32-bit library path).
This also affects compiler flag checks for "-lstdc++". Incorrect
library path results in error when checking for "-lstdc++", and
this flag will not be used for the build. This results in
undefined references when compiling C++ code.
This creates target_x86.cmake to add the necessary flags for
CMake to use. The target_x86_64.cmake is also created to
mirror the same change.
Also removing the -m32 flags for host-gcc since we are not
building x86 targets with the host-gcc compiler.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Depending on how compiler is built, it prints a different include
directory with `--print-file-name=include`. What we want, instead, is
directories with `stddef.h` and `include-fixed/limits.h`.
This commit explicitly specify the header files we want to use, then
take the directory from the returned path.
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
We need to pass -m64 instead of -m32 when CONFIG_64BIT is set.
This is pretty x86 centric. Many platforms don't have the ability
to select between 32-bits or 64-bits builds and either of those should
be dropped in that case with restriction on the available configuration
done elsewhere. But for the time being this allows for testing both.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The macro is intended to abstract the -fno-common compiler option
which controls the placement of uninitialized global variables. The
macro leaves it up to the toolchain to define the option.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro is intended to abstract the -imacros compiler option for
inclusion of the autoconf.h header file. The abstraction allows for a
given toolchain to decide how the inclusion of the header file is to
be done.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The introduced macros are placeholders for the cmake parameter warning
level.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Prepend -m32 to existing flags as opposed to silently override and
discard them:
- set(CMAKE_<tool>_FLAGS -m32 )
+ string(PREPEND CMAKE_<tool>_FLAGS " -m32")
This stops discarding additional flags passed with either cmake
-DCMAKE_<tool>_FLAGS="-fu -bar" or cmake -C params.cmake.
Note this bug was affecting only the combination of x86 and
CMAKE_<tool>_FLAGS. x86_64 wasn't affected and other, non-empty
CMAKE_<tool>_FLAGS_[DEBUG/RELEASE/etc.] weren't affected either.
Also convert flags string to list when invoking --print-libgcc-file-name
to support more than one CMAKE_C_FLAGS.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
- newlib needs c standard includes (so no -nostdinc)
- xcc needs toolchain headers (so no -nostdinc)
- with host gcc:
- x86_64 should not build with standard includes (-nostdinc needed)
- native_posix should build with standard include (no -nostdinc)
..
..
To simplify, abstract this and move it to compilers/toolchains and still
depend on what the application wants.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
XCC is based on xcc, but is nothing like gcc and his many differences.
Instead of ifdeffing the gcc code with Xcc specifics, maintain it
standalone.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduce toolchain_cc_asm macro to capture toolchain specific flags
related to assembly.
-D_ASMLANGUAGE is kept common for all, assuming -D as define flag is
supported by all compilers (which is almost the case).
No functional change expected.
Clang's flags are compatible with gcc, and are thus inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
We where defining the variable NOSTDINC_F after we tried to use it.
Move the definition before the first reference fixes things. When
-nostdinc now enabled we need to explicitly add the compiler include
path for x86_64 based builds (x86_64 and ARCH_POSIX).
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introduce toolchain_cc_cpp_*-family of macros.
Move the following into the toolchain_cc_cpp_* macros:
* Common base set of flags
* C++ standard version
* RTTI
* Exceptions
These macros must be implemented by every compiler port.
These macros set the respective flags, but leaves logic and control to
the root CMakeLists.txt file.
No functional change expected.
Clang's C++ flags are compatible with gcc, and are thus
inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Introduce toolchain_cc_optimize_for_* family of macros.
Each macro represents a general optimization class.
Each macro is then responsible for setting an output variable to that
class-of-optimization's flag.
The names of these output variables are decided from the root
CMakeLists.txt.
No functional change expected.
Clang's optimization flags are compatible with gcc, and are thus
inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
PR #9522 series ending with commit c2c9265b7d ("tests: cmsis: Disable
two cmsis portability tests on x86_64") added -mx32 support for the
x86_64 ARCH and qemu_x86_64. While this was implemented in
"compiler/gcc/target.cmake" as fall back from cross-compilation to the
host compiler, it worked with a direct ZEPHYR_TOOLCHAIN_VARIANT=host
too.
Later, -lgcc was added to "compiler/host-gcc/target.cmake" by PR #12674
to fix the -m32 x86 build. This broke the x86_64 build when using
ZEPHYR_TOOLCHAIN_VARIANT=host because even "multilib" packages usually
don't feature the -mx32 version of libgcc.
Fix this by excluding -lgcc in compiler/host-gcc/target.cmake just like
compiler/gcc/target.cmake always did for x86_64.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Introduce the first of the toolchain_cc-family of macros:
toolchain_cc_security_fortify and toolchain_cc_security_canaries.
No functional change expected.
Fortify source is not supported by Clang, but this commit retains
current behavior.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Add missing -lgcc when compiling with ZEPHYR_TOOLCHAIN_VARIANT=host
merely copying some existing code from
'compiler/{clang,gcc}/target.cmake'.
This fixes compilation for the following boards with an x86
microprocessor:
galileo, minnowboard, qemu_x86, qemu_x86_nommu, up_squared,
up_squared_sbl
Compilation of the following boards with an X86_IAMCU microcontroller
still fail with a "cannot find -lgcc" error:
arduino_101, qemu_x86_iamcu, quark_d2000_crb, quark_se_c1000_devboard,
tinytile
This is _not_ a regression because these boards _already_ failed with
"undefined reference to __udivdi3" and other libgcc symbols.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This fixes the following error on all x86 BOARDs (qemu_x86,
galileo,... see "make usage" for the complete list) when compiling
assembly files with ZEPHYR_TOOLCHAIN_VARIANT=host:
cc1: error: CPU you selected does not support x86-64 instruction set
This also fixes the following error when compiling minnowboard,
up_squared and up_squared_sbl boards with ZEPHYR_TOOLCHAIN_VARIANT=host:
cc1: error: -mpreferred-stack-boundary=2 is not between 3 and 12
This fix alone is not enough to compile any of these boards; however it
moves compilation much further to the next, unrelated failure(s),
namely: 'undefined __udivdi3' and other libgcc symbols for all x86
boards; + some other, additional issues for some boards. See next
commit.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Cosmetics, no functional change expected.
Fixed leading space alignment.
Replaced tabs with spaces.
Emulation error message output is now aligned.
To locate tabs in cmake, the following bash is useful:
grep -PRil "\t" * | grep -i cmake | grep -v ^sanity
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Split up the toolchain configuration into two phases, generic and
target. The 'generic' phase configures the toolchain just enough to be
able to preprocess DT files. The 'target' phase completes the
configuration with target-specific configuration.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Jeremy Bettis