Commit graph

171 commits

Author SHA1 Message Date
Tim Pambor
c8ef91fdb7 cmake: llvm: Use '=' for --config to improve compatibility
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>
2025-06-20 16:23:16 +02:00
Robin Kastberg
5a92e46c92 iar: toolchain: Implement IAR static init routine
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>
2025-05-12 19:18:56 +02:00
Daniel Leung
3cf5b0c8e8 cmake: toolchain/xcc,xt-clang: LD flag for multi-core env vars
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>
2025-04-30 23:02:56 +02:00
Björn Bergman
98ac4becab iar: toolchain: Enable TOOLCHAIN_HAS_BUILTIN_FFS
icc has support for __builtin_ffs() and its friends,
but it was disabled in the toolchain files.

Signed-off-by: Björn Bergman <bjorn.bergman@iar.com>
2025-04-01 11:51:41 +02:00
Lars-Ove Karlsson
8d3dcd79f4 logging: Added config to disable vla in statements
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>
2025-03-11 18:55:08 +01:00
Lars-Ove Karlsson
5a1f7a58db cmake: toolchain: Removed config FP16 from IAR kconfig.default
Removed config FP16 from kconfig.default as it is set by the arch/cpu.

Signed-off-by: Lars-Ove Karlsson <lars-ove.karlsson@iar.com>
2025-02-27 13:27:20 +00:00
Robin Kastberg
6d5dd34860 iar: toolchain: enable VLA for IAR
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>
2025-02-24 15:37:07 +00:00
Robin Kastberg
9ab06ec667 toolchain: iar: Add experimental IAR support
This adds experimental support for the IAR toolchain.

Signed-off-by: Robin Kastberg <robin.kastberg@iar.com>
2025-02-14 19:12:44 +00:00
Stephanos Ioannidis
3bb5c4b264 cmake: toolchain: Remove deprecated 'xtools' toolchain variant
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>
2025-01-17 10:50:07 +01:00
Daniel Leung
cdb9166b81 cmake: toolchain/xcc,xt-clang: env vars for multiple cores
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>
2024-10-31 09:26:00 -05:00
Daniel Leung
59b2163eeb cmake: toolchain/xt-clang: force assembler ID to GNU
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>
2024-10-31 09:26:00 -05:00
Daniel Leung
2dee8a4733 cmake: xcc: use xt-ld linker cmake code
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>
2024-10-15 19:08:47 -04:00
Torsten Rasmussen
0274bcbee4 cmake: detect LLVM picolibc and newlib support
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>
2024-10-04 16:34:35 +01:00
Torsten Rasmussen
2e3873adde cmake: improve Zephyr link phase
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>
2024-10-04 16:34:35 +01:00
Evgeniy Paltsev
021b5cd38f toolchain: arcmwdt: always enable TLS in case of CPP
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>
2024-07-12 06:22:13 -04:00
Jonathon Penix
97a734aa01 cmake: llvm: arm64: Set arm64 flags when building with clang
Ensure --target and -mcpu/-mfpu/-mtune are set appropriately when building
with clang targeting arm64/aarch64.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
2024-06-13 17:58:04 +02:00
Jonathon Penix
fb98adc323 kconfig: llvm: arm64: Advertise TLS support when using llvm for arm64
clang and lld both support TLS for arm64/aarch64, so advertise this
support in Kconfig.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
2024-06-13 17:58:04 +02:00
Chris Friedt
4a5c4e5f73 posix: timers: deprecate CONFIG_POSIX_CLOCK and TIMER
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>
2024-06-04 16:27:12 -05:00
Nikolay Agishev
3ccbef2d55 ARCMWDT: Turn off picolibc support
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>
2024-05-18 15:54:05 +03:00
Jonathon Penix
99adbadad5 toolchain: llvm: Allow TLS when using llvm targeting arm
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>
2024-05-14 09:43:37 +02:00
Nikolay Agishev
e97d33d0c8 ARCMWDT: Fix building under hwmv2 model
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>
2024-05-07 10:44:15 +02:00
Jonathon Penix
7d5ccc083c cmake: llvm: arm: Remove '--specs' when building with clang for arm
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>
2024-05-07 09:33:16 +02:00
Pieter De Gendt
cb459f12ba arcmwdt: Enable GNU C Extensions
Replace the global CSTD property with a Kconfig symbol selection.

Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
2024-04-25 09:54:39 +00:00
Pieter De Gendt
a599ed13a1 kconfig: Add symbols for GNU C Extensions
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>
2024-04-25 09:54:39 +00:00
Jonathon Penix
82a47cc06d kconfig: llvm: riscv: Advertise TLS support when using llvm for RISC-V
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>
2024-03-18 13:16:06 +01:00
Jonathon Penix
ba871733e0 cmake: llvm: riscv: Set RISC-V flags when building with clang
Ensure --target and -march/-mabi/-mcmodel are set appropriately when
building with clang targeting RISC-V.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
2024-03-18 13:16:06 +01:00
Pisit Sawangvonganan
65b6d2f180 toolchain: esp32: fix cmake build issue with 'espressif' toolchain
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>
2023-11-22 09:52:29 +01:00
Fabio Baltieri
fd9a464495 toolchain: llvm: use the "none" vendor triplet
This was submitted with "cros" in 77dde5dc9f, it was meant to be "none".

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2023-11-15 13:05:01 +01:00
Marc Herbert
0fead68e2b Revert "llvm: use proper syntax for --config option"
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>
2023-08-31 10:24:29 +02:00
Benjamin Cabé
577d47f3f1 llvm: use proper syntax for --config option
Use proper --config= syntax instead of --config as the latter can cause
issues in some situations.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
2023-08-23 16:07:54 +01:00
Patryk Duda
4b94fc3da2 llvm: Add support for selecting runtime library
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>
2023-08-03 19:35:11 +02:00
Patryk Duda
77dde5dc9f llvm: Add ARMv6-M, ARMv7-M, ARMv8-M Mainline and Baseline targets
Introduce more specific ARM targets basing on enabled options in
Kconfig.

Signed-off-by: Patryk Duda <pdk@semihalf.com>
2023-08-01 11:08:36 +02:00
Evgeniy Paltsev
c75bf5ebc5 ARC: MWDT: cleanup search path handling
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>
2023-06-29 10:03:35 +00:00
Evgeniy Paltsev
b64cfe9832 ARC: MWDT: rework GNU helper tools usage
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>
2023-06-17 07:44:31 -04:00
Kumar Gala
ca4dc50ec1 libc: Move strnlen into common
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>
2023-05-08 09:59:27 +02:00
Keith Packard
28209a9069 cmake/toolchain: Add Kconfig setting for toolchains with newlib
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>
2023-04-27 20:18:11 +09:00
Keith Packard
02262d7367 lib/libc: Replace SUPPORT_MINIMAL_LIBC with MINIMAL_LIBC_SUPPORTED
Clean up libc-related symbols to use a common pattern.

Signed-off-by: Keith Packard <keithp@keithp.com>
2023-04-27 20:18:11 +09:00
Evgeniy Paltsev
1f57517e2c ARC: ARCMWDT: check METAWARE_ROOT if ARCMWDT_TOOLCHAIN_PATH missing
ARC MWDT toolchain installation provides METAWARE_ROOT environment
variable. Let's check METAWARE_ROOT environment variable if
zephyr-specific option ARCMWDT_TOOLCHAIN_PATH missing.

That improves user experience.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
2023-03-30 13:49:40 +02:00
Daniel Leung
fb350bca10 toolchain: llvm: defer setting target triple to target.cmake
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>
2023-03-29 19:48:47 -04:00
Daniel Leung
a5cc22b2a9 toolchain: defer setting variable LINKER till target tools
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>
2023-03-29 19:48:47 -04:00
Daniel Leung
4d914f4f89 toolchain: move CONFIG_LLVM_USE_LD into cmake/toolchain/llvm
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>
2023-03-29 19:48:47 -04:00
Daniel Leung
7864caba1b linker: llvm: provide a default config file for clang
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>
2023-03-29 19:48:47 -04:00
Kumar Gala
672aeace88 libc: share time() between minimal libc and armclang libc
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>
2023-03-27 09:49:40 +02:00
Marcin Niestroj
b03d27cca3 toolchain: esp32: support esp32s3 in 'espressif' toolchain
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>
2023-03-06 13:52:55 +01:00
Kumar Gala
2d12766e78 toolchain: oneApi: Fix support and update for 2023.0.0 release
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>
2023-02-23 14:30:03 -05:00
Daniel Leung
4683c8d4d5 linker: introduce profile xt-ld
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>
2023-02-22 08:35:46 -05:00
Daniel Leung
53316d5c8e toolchain: rename xcc-clang to xt-clang
This reflects the actual compiler executable name of the Xtensa
LLVM/Clang compiler.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-02-22 08:35:46 -05:00
Evgeniy Paltsev
ae79de1930 ARC: MWDT add TLS support
Add thread local storage support for ARC MWDT toolchain.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
2022-11-29 09:48:23 +01:00
Stephanos Ioannidis
a9d85ae472 cmake: Deprecate 'xtools' toolchain variant
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>
2022-11-17 15:42:48 +09:00
Torsten Rasmussen
fd9e5429a3 cmake: detect sysroot for cross-compile toolchains
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>
2022-09-23 16:37:44 +02:00