MetaWare toolchain doesn't support building Zephyr with
Picolibc module. This PR fixes biuld process by turning off
picolibc support on compiler side.
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
TLS for Arm targets seems to be well supported in clang/lld, so mark it as
supported by the toolchain.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
On very early stage build system needs to get access to DTC preprocessor.
MWDT has no it's own preprocessor, so here zephyr-SDK preprocessor is used.
On latest build stages zephyr-SDK objcoby also required as MWDT binutils
don't support all features. This at the same time requires that
ZEPHYR_SDK_INSTALL_DIR must be initialized with valid arch-dependent
prefix.
Zephyr-SDK requires ARCH variable to be initialized before
include "generic.cmake", but in hew HWMv2 model ARCH variable will be
initialized more later. This workaround uses any (first awailable,
independent on ARCH) toolchain from SDK for DTC preprocessing only.
For other build stages ARCMWDT will be used.
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
Currently, clang produces a warning that the '--specs=nosys.specs' argument
is unused. Remove this flag to fix the warning as clang will generally not
honor '--specs' when targeting arm baremetal.
While this flag has been present for some time, I think this should be safe
to do. For background, clang does not seem to handle '--specs' [1] besides
possibly passing it through to GCC if GCC is used as the driver for
linking. However, whether GCC will be used for linking as a fallback
depends on the "Toolchain" [1] clang uses internally, which in turn depends
on the triple. For arm/thumb baremetal triples, the Toolchain clang uses
will not fall back to GCC to drive linking, so '--specs' will never be used
here.
I believe this behavior in clang is fairly longstanding as well (since
~2017/LLVM 5 [2]). While there isn't a minimum required clang version for
Zephyr, Zephyr currently requires lld >= 14.0.0. So, I don't think removing
this flag should impact current users (besides preventing the warning).
[1] https://clang.llvm.org/docs/DriverInternals.html
[2] https://reviews.llvm.org/D33259
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Add a symbol to enable GNU C Extensions. And a hidden option for
toolchains to signal GNU Extensions support.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
clang and lld support TLS for RISC-V, so advertise this support in
Kconfig. I believe other non-RISC-V targets also have TLS support in LLVM,
but I'm not sure on the exact subset. As TLS support in LLVM wasn't
automatically advertised previously, gate this on RISC-V for now as it
a) shouldn't break other targets and b) prevents us from improperly
claiming support for unsupported targets.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Ensure --target and -march/-mabi/-mcmodel are set appropriately when
building with clang targeting RISC-V.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Change CROSS_COMPILE_TARGET to be defined based on CONFIG_SOC_SERIES.
This fix adjusts CROSS_COMPILE_TARGET to ensure compatibility
with the 'espressif' toolchain variant, following the changes in
commit 6b57b3b786.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
This reverts commit 577d47f3f1.
The --config= syntax with the equal sign does not work with clang 15
which is less than one year old (https://releases.llvm.org/). It does
not work with clang 14 either.
```
clang --verbose
clang version 15.0.7
clang --help | grep config
-cl-std=<value> OpenCL language standard to compile for.
--config <value> Specifies configuration file
--cuda-feature=<value> Manually specify the CUDA feature to use
clang: error: unsupported option '--config=/home/runner/work/...
```
The reverted commit mentioned "issues in some situations" without
providing any example or other information.
This revert fixes the SOF fuzzer build, see more details in #61778.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Use proper --config= syntax instead of --config as the latter can cause
issues in some situations.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This patch adds Kconfig options to select either GNU libgcc or LLVM
compiler-rt. The 'rtlib' flag is provided in a config file, so this
patch introduces 'clang_libgcc.cfg' and 'clang_compiler_rt.cfg' which
enable appropriate library. The file is selected by concatenating
the 'clang_' prefix with library name.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Cleanup ARC MWDT search path handling:
* Don't print warning if ARCMWDT_TOOLCHAIN_PATH is missing but
METAWARE_ROOT is set. Treat it as valid case and do message
with status level instead of warning.
* Make rest of the error messages more understandable for users.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
As of today MWDT toolchain in case of Zephyr may use few
tools from GNU toolchain - GNU compiler for DTS preprocessing
and objcopy for section renaming.
Currently we were trying to find any GNU compiler & objcopy
which start to cause compatibility issues for new targets -
i.e. not every objcopy knows new ARC targets.
Let's use ARC GNU tools from Zephyr SDK as we still usually
require it when building with MWDT for other tools like DTC
(device tree compiler)
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Move the strnlen implementation into common so its available to any
libc that may not implement strnlen.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Label espressif, gnuarmemd and xtools toolchains with newlib support using
the Kconfig variable rather than relying on the TOOLCHAIN_HAS_NEWLIB
value.
Signed-off-by: Keith Packard <keithp@keithp.com>
Since kconfigs are not available when generic.cmake is parsed.
Setting the target triple for x86 needs to be deferred to
target.cmake as it needs to know whether CONFIG_64BIT is
enabled. This also moves the ARM triple to target.cmake as
triple is needed for target tools.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The variable LINKER is dependent on CONFIG_LLVM_USE_LLD
or CONFIG_LLVM_USE_LD, and these kconfigs are not
available when toolchain/llvm/generic.cmake is parsed.
So setting LINKER needs to be deferred to target.cmake
where kconfigs are available.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This moves CONFIG_LLVM_USE_LD into cmake/toolchain/llvm as this
is a toolchain kconfig. Also make it a choice to allow the use
of LLVM's lld as linker.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Some distros may provide config files for clang to change its
default behavior. We need to override that, or else developers
may be using different defaults and we will have confusing
bug reports in the future.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Introduce a place to share implementations of libc functions that
are needed by different libc versions. Place time() in this common
location so it can be shared when building for either minimal libc or
armclang libc.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
CROSS_COMPILE_TARGET is defined based on CONFIG_SOC selected. So far
'esp32s3' SoC was not taken into account, so building Zephyr with
'espressif' toolchain (the only one supported for now) is was not possible
out of the box.
Add 'CROSS_COMPILE_TARGET_xtensa_esp32s3' CMake variable, same as it is
done for other SoC specific variables. That way toolchain paths are
automatically figured out and building succeeds.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
The oneApi support has bit rotten since it was first introduced. Update
the support to function with the latest 2023.0.0 release and add a
check to only support that version or newer for now. Versions before
2021.2.0 have linker script failures.
Various fixes made:
* In the 2023.0.0 release, various binaries are in a llvm-bin path so
add support to search in that path. This replaces the python search
path that much older versions needed.
* newlib isn't supported with oneApi so set TOOLCHAIN_HAS_NEWLIB to
OFF to match that.
* 2023.0.0 doesn't back llvm-nm, so use binutils version. This
is expected to be fixed in 2023.1.0 release so add a check to
handle either case.
* Update compiler flag check based on clang to also support
CMAKE_C_COMPILER_ID of "IntelLLVM" as that is how the oneApi toolchain
reports itself.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Xtensa toolchain has its own linker, xt-ld, which is based on
binutils' ld. There are, of course, Xtensa specific options.
But mostly it is based on old version of ld. It would be
better to detach it from the ld profile to avoid any
incompatible changes there.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The `xtools` toolchain variant (aka. Crosstool-NG) was originally
introduced to be used with the Crosstool-NG-based Zephyr SDK
toolchains (i.e. sdk-ng).
This is no longer necessary because the current Zephyr SDK (sdk-ng)
already has its own `zephyr` toolchain variant, which fully replaces
the `xtools` toolchain variant, and the `xtools` toolchain variant
serves no purpose at all.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
Fixes: #49587
Try to detect sysroot for cross-compile toolchain if not specified by
the user with `-DSYSROOT_DIR=<path>`.
First, the C compiler is asked if it knows its sysroot, some C compilers
are able to return the sysroot, as an example:
> $ arm-none-eabi-gcc -print-sysroot
> <path>/bin/../arm-none-eabi
> $
but majority of gcc-based C compilers seems to return empty string:
> $ arm-zephyr-eabi-gcc --print-sysroot
> $
in such cases, the cross-compiler target CMake file will try to discover
the sysroot by searching for libc.a, starting one level up from the
compiler location.
If no sysroot candidate is found, a warning will be printed to the user.
If a single sysroot candidate is found, this candidate will be selected.
If multiply sysroot candidates are found, a warning is printed, and the
first candiate in the list is selected. User may select another
candidate with `-DSYSROOT_DIR=<use-this>`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add a user-settable configuration value indicating whether the toolchain
selected by the cross-compile variant supports thread local storage, using
the default 'n' value to preserve compatibility with existing uses.
Signed-off-by: Keith Packard <keithp@keithp.com>
The Zephyr cross tools configuration which the 'xtools' variant supports
enables TLS, so set TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE when using it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: #40389
Update toolchain handling to use zephyr_get() to ensure consistent
handling of CMake cache variables, environment variable, and CMake
local variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Follow-up: #41301
This commit is a rework and cleanup of the tools handling in Zephyr
CMake build system.
Instead of directly loading code a CMake modules for tool lookup, the
host tools now follows the CMake `find_package()` pattern for finding
programs / tools in module mode.
This makes it more clear which modules are responsible for finding tools
and which modules provides build integration / features.
The following tools can now be found using `find_package()`:
- Zephyr-sdk : find_package(Zephyr-sdk <version>)
- Generic host tools: find_package(HostTools)
This further allows us to decouple the `verify-toolchain` CMake script
part required by `twister` into a tool lookup module and a dedicated
CMake script which utilizes the lookup module.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
Instead of setting XCC_USE_CLANG=1, this patch adds xcc-clang toolchain
that is basically xcc using the clang compiler.
Initially, the new toolchain simply includes files from current xcc
toolchain and (re)sets some variables. This should be a more scalable
approach to diverge the toolchains in the future than placing
"if($ENV{XCC_USE_CLANG})" at several places.
It should also help to filter tests that run (or not) exclusively with
the clang variant of XCC on twister.
The XCC_USE_CLANG flag is documented as deprecated, and a message is
emitted during build if still in use. Its new behaviour is to instruct
Zephyr to use `xcc-clang` toolchain.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
GCC-based XCC uses GNU Assembler (xt-as). However, CMake doesn't
recognize it when invoking through xt-xcc. This results in CMake
going through all possible combinations of command line arguments
while invoking xt-xcc to determine assembler vendor. This multiple
invocation of xt-xcc unnecessarily lengthens the CMake phase of
build, especially when XCC needs to obtain license information
from remote licensing servers. So here forces the assembler ID
to be GNU to speed things up a bit.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Remove xtensa specific workaround as this code is now present in Zephyr
SDK cmake code.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
With the revert of commit 820d327b4618d587a9cae0d085f00c6ab9c81cf2 then
some additional code can be cleaned up.
This removes the final left-overs from Zephyr SDK 0.11.1 support and
older.
It further aligns message printing when including Zephyr SDK toolchain
to other toolchain message printing.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This reverts commit 820d327b4618d587a9cae0d085f00c6ab9c81cf2.
Commit b973cdc9e8 updated the minimum
required Zephyr SDK version to 0.13.
Therefore revert commit 820d327b4618d587a9cae0d085f00c6ab9c81cf2 as
backward support for 0.11.1 and 0.11.2 is no longer required.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
In order to retrieve TOOLCHAIN_NAME from Kconfig,
generic.cmake points to any toolchain as a
boilerplate implementation. Now, target.cmake file handles
proper toolchain selection.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Support for ARM Compiler C library.
This commit add support for the ARM Compiler C libary in:
- Kconfig
- libc/armstdc
A new Kconfig symbol is added to allow a toolchain to specify if they
support linking with the minimal C library.
Also the CMake variable `TOOLCHAIN_HAS_NEWLIB` is exported to Kconfig
so that CONFIG_NEWLIB_LIBS can only be enabled if the toolchain has
newlib.
The armclang toolchain selects the CMake scatter file generator and
disables support for the LD linker template which is not supported by
armlink.
For the ARM Compiler C library, a corresponding lib/libc/armstc/ folder
with a minimal implementation to work with the ARM Compiler C library
is added.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
