Add TriCore target configuration for GCC and Clang compilers.
Include target_tricore.cmake for both toolchains with TriCore
specific compiler and linker flags.
GCC and Clang use different -mcpu identifiers for the same
silicon: GCC uses tc39xx/tc4DAx while Clang uses tc3xx/tc4xx.
GCC builds additionally require -mno-eabi-bitfield-limit to
relax the EABI half-word boundary crossing restriction for
bitfields and -fstrict-volatile-bitfields for correct MMIO
register access.
Select lld as the linker for TriCore Clang builds. Enable
TriCore in the host LLVM toolchain Kconfig.
Signed-off-by: Christoph Seitz <christoph.seitz@infineon.com>
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
The Hexagon cross-toolchain is an ordinary LLVM installation whose clang
only registers the Hexagon target, so the host/llvm variant already
describes how to drive it. Give it a variant of its own anyway, reading
HEXAGON_TOOLCHAIN_PATH rather than LLVM_TOOLCHAIN_PATH.
The reason is that a build environment commonly holds two LLVMs: a native
one, used for native_sim and other host-compiled targets, and this
Hexagon-only one. A single LLVM_TOOLCHAIN_PATH cannot name both, and
whichever it names wins for the whole run -- Zephyr's own CI sets it to
the distribution LLVM for every builder, so a Hexagon platform sharing
that variable is handed a compiler with no Hexagon runtime and fails at
the link:
ld.lld: error: unable to find library -lclang_rt.builtins
Two variables let one Twister run cover both kinds of platform, and let a
run with no Hexagon toolchain installed filter the board out cleanly
rather than trying to build it with the wrong compiler.
The variant also withdraws TOOLCHAIN_HAS_LIBCXX, which host/llvm declares
unconditionally: the Hexagon toolchain ships libc++ only for
hexagon-unknown-linux-musl, not for the bare-metal
hexagon-unknown-none-elf target Zephyr builds against, so a C++
configuration picked on the strength of that declaration fails at the
first standard header.
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add Hexagon DSP architecture support to Zephyr RTOS, targeting the
Qualcomm Hexagon V67+ ISA running as a guest under the H2 hypervisor.
This includes:
- Architecture scaffolding (Kconfig, CMakeLists, arch selection)
- Public headers (arch.h, thread.h, exception.h, error.h)
- Core runtime: context switch, interrupt/exception handling, idle, TLS
- Memory management stubs for flat-memory H2 guest model
- SoC support for QEMU hexagon virt machine
- CMake/LLVM toolchain integration for hexagon cross-compilation
Hexagon uses H2's GEVB (Guest Event Vector Base) for interrupt dispatch
rather than a traditional function-pointer vector table, so
GEN_IRQ_VECTOR_TABLE is disabled by default.
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Now that the minimum required CMake version is 3.28.0, remove version
checks and workarounds that can no longer trigger:
- the PyPI CMake 3.22.1 / 3.22.2 cmake_path() bug detection
- the CMakeError.log fallback name for the configure log, which has
been CMakeConfigureLog.yaml since CMake 3.26
- the armclang generator check for CMake < 3.21
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add the XC32 toolchain configuration files needed for Zephyr
to detect and use the Microchip compiler toolchain with the
expected compile/link defaults.
Signed-off-by: Ashish Mahanth <ashish.mahanth@microchip.com>
Use zephyr_get() with VAR fallback to resolve CROSS_COMPILE and
CROSS_COMPILE_TOOLCHAIN_PATH per board target, falling back to the
global variable. This follows the same pattern used by XTENSA_CORE
in xcc/common.cmake.
Users can now set CROSS_COMPILE_<normalized_board_target> to specify
different toolchain prefixes for different boards without changing
the global CROSS_COMPILE between builds.
Signed-off-by: Anil Ozrenk <anil.ozrenk@analog.com>
The iar toolchain fails to build after the update to the
1.0.0 Zephyr SDK. The path to the gnu toolchains
was updated to '${ZEPHYR_SDK_INSTALL_DIR}/gnu/'
in order to be compatible with the 1.0.0 SDK.
Signed-off-by: Jason Yu <zejiang.yu@nxp.com>
The arcmwdt toolchain fails to build after the update to the
1.0.0 Zephyr SDK. The path to the generic.cmake in the toolchain
was updated to '${ZEPHYR_SDK_INSTALL_DIR}/cmake/zephyr/gnu/target.cmake'
in order to be compatible with the 1.0.0 SDK. This commit also
sets the required zephyr SDK to 1.0 as the SDK is no longer backwards
compatible and will fail to build with any version less than 1.0.
Signed-off-by: Christopher Turner <christopher.g.turner@intel.com>
The espressif toolchain variant (ZEPHYR_TOOLCHAIN_VARIANT=espressif)
has not been used for years. Espressif targets are now built using the
Zephyr SDK, which bundles the required Xtensa and RISC-V toolchains.
Remove the cmake/toolchain/espressif/ directory containing generic.cmake,
target.cmake, and Kconfig files that implemented this variant. Also
clean up references in the coredump xtensa gdb stubs, removing the
ESPRESSIF toolchain enum value and related handling code.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Until https://github.com/zephyrproject-rtos/sdk-ng/pull/936 is merged,
SDK 0.18 is incompatible with previous versions as the paths to
find the cmake bits is different.
Deal with that by checking for files in the wrong place as well as the
right one.
Signed-off-by: Keith Packard <keithp@keithp.com>
Support specifying compiler type for Zephyr SDK in the
ZEPHYR_TOOLCHAIN_VARIANT variable.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Combine toolchains provided by the host into one variant. This includes
both gcc and llvm installation typically coming from the distribution
(on Linux).
Both gcc and llvm are now part of the 'host' variant, the default is the
gnu compiler, so setting
ZEPHYR_TOOLCHAIN_VARIANT=host
Will select the gnu compiler. To select llvm or any other compuler
provided in this variant, use the follwoing format:
ZEPHYR_TOOLCHAIN_VARIANT=<variant>/<compiler>
The following will select llvm:
ZEPHYR_TOOLCHAIN_VARIANT=host/llvm
Although gnu is the default, it can also be selected using the above
syntax:
ZEPHYR_TOOLCHAIN_VARIANT=host/gnu
This commit removes the llvm variant for now, it should be deperecated
in another commit to follow.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit introduces `TOOLCHAIN_HAS_LIBCXX` CMake variable, which is set
to `y` when LLVM C++ Standard Library aka. libc++ is available.
This helps filter libc++-specific Kconfig and tests in a more refined
manner.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit introduces `TOOLCHAIN_HAS_GLIBCXX` CMake variable, which is
set to `y` when GNU C++ Standard Library aka. libstdc++ is available.
This helps filter libstdc++-specific Kconfig and tests in a more refined
manner.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
- Add a hidden symbol to indicate variable cleanup attribute support.
- Add a symbol to enable cleanup helper macros.
- Provide a macro for the cleanup attribute in the GCC toolchain.
- Disable IAR toolchain support.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
`armclang` doesn't support picolibc right now so disable it and fix
few issues related to it as below:
```
zephyrproject/zephyr/lib/libc/validate_libc.c:17:14: error: static
assertion failed due to requirement 'sizeof(unsigned int) >= 8': time_t
cannot hold 64-bit values
17 | BUILD_ASSERT(sizeof(time_t) >= 8, "time_t cannot hold 64-bit
values");
```
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
This adds the compiler flag to instruct xt-clang not to generate
FLIX (Flexible Length Instruction Xtensions) instructions, where
multiple instructions can be fused into one instruction. FLIX
can provide performance and code size advantages.
When userspace is enabled, FLIX may reorder memory access
where memory is accessed before code determines whether
we should perform that memory access. For example,
when guarding memory access via k_is_user_context(), and
some kernel variables can only be accessed via kernel mode,
FLIX may reorder memory access such that these variables are
accessed before k_is_user_context(). This results in access
violation. This turns off FLIX generation by default and
lets the application developers to decide whether to enable
FLIX generation.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Change the toolchain version resolution order to check for
board-specific TOOLCHAIN_VER_${NORMALIZED_BOARD_TARGET} first,
falling back to the generic TOOLCHAIN_VER if not defined.
Now if we want to use various boards lots of them uses same version
but fewer ones differ. We won't have to define TOOLCHAIN_VER for
every board.
Signed-off-by: Anil Ozrenk <anil.ozrenk@analog.com>
Do not use private API prefix and move to architecture interface as
those functions are primarily used across arches and can be defined by
the architecture.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Commit f499ea0 made it so that the compiler optimization flags are also
passed to the assembler. However, this breaks for the IAR toolchain
since it uses the GNU assembler which does not have the same
optimization flags as the IAR compiler.
This commit separates the compiler and assembler optimizations to make
it possible to specify appropriate flags in a toolchains corresponding
`compiler_flags.cmake`
Signed-off-by: Daniel Flodin <daniel.flodin@iar.com>
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>
