Replaces space with an equal sign when assigning the clang configuration
file to the --config parameter. This change improves compatibility with
tools that parse the compilation database and expect compiler arguments
to be separated by space.
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
This will implement a way of doing static initialization
the "IAR" way. This is done by calling __iar_data_init3
which handles all static initialization that is mentioned
in the linker file "initialize by copy".
Signed-off-by: Robin Kastberg <robin.kastberg@iar.com>
When using one set of environment variables for multiple
cores compilation, we also need to supply the core name in
linker flags. So add that to TOOLCHAIN_LD_FLAGS.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The config LOG_USE_VLA depends on that MISRA_SANE is not set.
Unfortunately the IAR toolchain can't handle vla:s inside a
statement, which the LOG_USE_VLA macro does.
I've added a new, hidden config to check if vla is ok inside
statements, SUPPORT_VLA_IN_STATEMENTS. Default is always y, but
a toolchain can override it so that VLA is not used by
Z_LOG_MSG_ON_STACK_ALLOC.
Signed-off-by: Lars-Ove Karlsson <lars-ove.karlsson@iar.com>
Currently some subsystems outside the zephyr kernel
use VLA:s such as bluetooth. We will enable it for now
in the same kind of situations as gcc.
Signed-off-by: Robin Kastberg <robin.kastberg@iar.com>
The `xtools` toolchain variant, which was originally introduced to be used
with the Crosstool-NG-based Zephyr SDK toolchains and has been replaced by
the `zephyr` toolchain variant, has been marked as deprecated since Zephyr
v3.3.0.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
To use Xtensa toolchain, various environment variables must be
set so the executables can find necessary files and what core
to compile for. This becomes an annoyance when you have to
test multiple boards with different cores. You have to use
one set of environment variables per core. Twister cannot test
them all in one setting, and it is especially annoying doing
west builds. So enhance the environment variables handling so
that TOOLCHAIN_VER and XTENSA_CORE can be replaced by
TOOLCHAIN_VAR_<board> and XTENSA_CORE_<board> where <board>
is the normalized board target (think <board>.yaml). CMake
will then figure out the core ID for the toolchain to use.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
xt-clang uses GNU Assembler (xt-as) based on binutils. However,
CMake doesn't recognize it when invoking through xt-clang. This
results in CMake going through all possible combinations of
command line arguments while invoking xt-clang to determine
assembler vendor. This multiple invocation of xt-clang
unnecessarily lengthens the CMake phase of build, especially
when xt-clang 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>
Shuffling of ld/lld on C library linking cmake code causes
issue with XCC as the HAL library is not being included in
linking. So make XCC to use xt-ld linker cmake code such
that the HAL library is included.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Newlib or Picolibc libraries for LLVM may be compiled or installed from
pre-built sources independently of LLVM itself.
This means that always indicating that TOOLCHAIN_HAS_NEWLIB=OFF and
TOOLCHAIN_HAS_PICOLIBC=OFF are wrong. But it could be just as wrong to
always indicate suport for newlib or picolibc.
Some pre-built LLVM toolchains are provided with default picolibc
support, such as LLVM for Arm embedded, but can also be used with newlib
be installing newlib add-on package.
Unfortunately it's not possible to query LLVM regarding newlib or
picolibc support.
Developers have the option of `-DTOOLCHAIN_HAS_<NEWLIB|PICOLIBC>=ON`,
but this is not widely known and cumbersome to do for each build.
An indication of newlib or picolibc support is the presence of library
specific headers, so to improve current situation we check for library
specific headers, and if those are present we assume support for the
library.
This commit improves the current support for LLVM in Zephyr when
cross-compiling, especially for users of LLVM for Arm embedded.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Zephyr is a bare metal build where standard libs are disabled.
This means that c and runtime libraries must manually be linked in.
This has generally been handled by using CMake's link libraries handling
but the issue with that is both de-duplication but also library link
order.
Standard libraries must be linked at last location to ensure symbols
are always available, however this is not optimal with
target_link_libraries() because this would ultimately require every
library to know the c library to link with, which is not desired.
Therefore, setup standard C and runtime library linking in linker
CMake files for toolchains where this is required.
This commit expands the principle introduced with toolchain abstraction,
see PR#24851.
This means that a toolchain implementation may specify standard C,
runtime, C++, etc libraries, as well as their link order.
Because a property approach is used, then Zephyr modules, such as the
Picolibc module can adjust such properties.
An optional `zephyr_linker_finalize()` macro is called at the end of
Zephyr's CMakeList process and can be used by the toolchain
implementation to define the final linker invocation.
This aligns the linker handling flow to the principle introduced in
PR#24851 and improves the flexibility and robustness of Zephyr build
system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The CPP in ARC MWDT toolchain relies on TLS (THREAD_LOCAL_STORAGE)
so enable it if CPP is selected.
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Ensure --target and -mcpu/-mfpu/-mtune are set appropriately when building
with clang targeting arm64/aarch64.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
The POSIX_CLOCK option does not correspond to any standard
option. It was used to active features of several distinct
POSIX Options and Option Groups, which complicated API and
application configuration as a result.
POSIX_CLOCK is being deprecated in order to ensure that Zephyr's
POSIX Kconfig variables correspond to those defined in the
specification, as of IEEE 1003.1-2017.
Additionally, CONFIG_TIMER is being deprecated because it does
not match the corresponding POSIX Option (_POSIX_TIMERS).
With this deprecation, we introduce the following Kconfig
options that map directly to standard POSIX Option Groups by
simply removing "CONFIG_":
* CONFIG_POSIX_TIMERS
Similarly, we introduce the following Kconfig options that
map directly to standard POSIX Options by simply removing
"CONFIG":
* CONFIG_POSIX_CLOCK_SELECTION
* CONFIG_POSIX_CPUTIME
* CONFIG_POSIX_DELAYTIMER_MAX
* CONFIG_POSIX_MONOTONIC_CLOCK
* CONFIG_POSIX_TIMEOUTS
* CONFIG_POSIX_TIMER_MAX
In order to maintain parity with the current feature set, we
introduce the following Kconfig options that map directly to
standard POSIX Option Groups by simply removing "CONFIG_":
* CONFIG_POSIX_MULTI_PROCESS - sleep()
Similarly, in order to maintain parity with the current feature
set, we introduce the following additional Kconfig options that
map directly to standard POSIX Options by simply removing
"CONFIG":
* CONFIG_XSI_SINGLE_PROCESS - gettimeofday()
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
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>
