Removes functions that would handle deprecated variables and
functionality from CMake within Zephyr that were deprecated in
Zephyr 3.1 onwards but before 3.7
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Rewrote the warning levels for toolchain IAR as IAR tools just turn
off warnings, not on. Also did some minor cleanup for coding
guidelines.
Signed-off-by: Lars-Ove Karlsson <lars-ove.karlsson@iar.com>
xt-clang is usually based on older version of clang, and
Zephyr main targets more recent versions. Because of this,
some newer compiler flags may cause warnings where twister
would mark as test being failed. To workaround that,
add -Wno-unknown-warning-option to suppress those warnings.
Fixes#84138
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Introduce GCC_COMPILER_VERSION to be used in Zephyr CMake when knowledge
of the current GCC Compiler version is needed and
CMAKE_C_COMPILER_VERSION has not been defined yet.
CMAKE_C_COMPILER_VERSION is not defined until project() is called.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
CMSIS modules dsp and nn sets the optimization flag -Ofast for their
libraries. I've now made a new compiler property optimization_fast to
avoid using ifdefs in the cmsis CMakeLists.txt files.
I've update GCC and arcmwdt (not sure if arcmwdt supports -Ofast)
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>
On RISC-V, GCC and possibly other compilers include small globals in
special "small data" sections like .sbss and .sdata.
This allows accessing these globals using the global pointer register
and an offset, which is faster than ordinary relocations.
Currently, llext_load does not support multiple NOBIT sections.
Thus, llext's that use both .bss and .sbss sections cannot be relocated.
Also, the global pointer cannot be used in llext's, as it does not
change when calling into or returning from an llext, making the
optimization pointless for llext.
This commit disables the use of small data sections by adding the
appropriate compiler flag when compiling llext's.
In addition to solving the aforementioned issue, this fixes llext's
test_inspect on RISC-V.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
Add the -imacros property for assembler language to compensate
for changes introduced in PR #84800.
Signed-off-by: Björn Bergman <bjorn.bergman@iar.com>
The IAR linker does not handle Dwarf 5 and since it uses the GCC
assembler for assembler files, we need to make sure the assembler
output uses Dwarf 4.
Signed-off-by: Lars-Ove Karlsson <lars-ove.karlsson@iar.com>
Some basic flags that were hardcoded needed
to be moved to properties to be able to implement
alternative toolchains.
Signed-off-by: Robin Kastberg <robin.kastberg@iar.com>
Enforces bitness match of ARC compilers and linkers invoked
building LLEXT apps by inheriting -mcpu flag from Zephyr.
The ARC toolchain becomes confused without the -mcpu flag.
On qemu_hs5x we see GCC select elf32-littlearc64 for
linking an object previously compiled as elf64-littlearc64.
Fixes#80949
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
The Zaamo and Zalrsc Extension (Version v1.0.0, 2024-04-25; Ratified) split
the standard A extension into two subextensions. As of date, the `_zaamo`
and `_zlrsc` extension specifications are accepted by the upstream
in-development GCC through the `march` argument. This means that those
subextensions are not yet supported by GCC shipped with Zephyr SDK.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
GCC versions starting from 4.3.0 until 12.4.0 stored the limits.h header in
a directory named include-fixed/ . Before 4.3.0 and after 12.4.0 i.e. from
13.1.0 onward, the header is stored in a directory named include/ .
Previously, target.cmake would only detect if the GCC version was 13.1.0 or
newer. This patch adds a check to also check if it is older than 4.3.0.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
GCC versions before 7.1.0 do not have the -fno-printf-return-value flag and
give an error if it is used. This patch improves compatibility with older
compilers by making CMake check for the flag's availability before using.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
The -fdiagnostics-color flag is only on GCC versions 4.9.0 and newer.
Previously, CMake only checked that the compiler was not the XCC compiler
before using the flag.
However, given that the flag us unavailable on compilers other than XCC,
e.g. old versions of GCC, this patch replaces the previous logic with a
flag-check using the check_set_compiler_property() CMake function.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
This patch changes the way extensions are built to allow for debugging
information to be collected. Debug flags are now used when compiling and
linking the extension source code, generating a debuggable ELF file.
The final .llext file is then stripped of unneeded symbols, including
all debugging information, at packaging time.
The debugging flag is still removed from the EDK-exported flags.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
This reverts commit 9d849d92bf that seems to
be causing dozens of basic kernel test failures across various platforms.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
STACK_CANARIES was enabling canaries in all functions using the compiler
flag -fstack-protector-all. This became confuse with the addition of the
options STRONG and EXPLICIT.
This commit adds the missing option (default level) and disambiguous the
options mapping them close to the compiler flags.
Now we have the following options:
STACK_CANARIES -> fstack-protector
STACK_CANARIES_STRONG -> fstack-protector-strong
STACK_CANARIES_ALL -> fstack-protector-all
STACK_CANARIES_EXPLICIT -> fstack-protector-explicit
Note that from now on STACK_CANARIES_ALL is the symbol that adds canaries
for all functions.
Signed-off-by: Flavio Ceolin <flavio.ceolin@gmail.com>
Add option to enable stack canaries only when explicitely
declared. It adds a new function attribute, __stack_protect, that
can be used to enable stack protection in a function.
Signed-off-by: Flavio Ceolin <flavio.ceolin@gmail.com>
Previously, when stack canaries were enabled, Zephyr applied this
protection to all functions. This commit introduces a new option that
allows stack canary protection to be applied selectively to specific
functions based on certain criteria.
Signed-off-by: Flavio Ceolin <flavio.ceolin@gmail.com>
CMakeLists.txt uses the C compiler parameter -include,
This is causing issues for other toolchains and needs to generalized.
Signed-off-by: Robin Kastberg <robin.kastberg@iar.com>
The LLEXT linker for Xtensa cannot relocate FLIX commands, disable
them in extensions only until we have a solution. Note, that this
only affects extensions, the main Zephyr binary is still built with
FLIX commands.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Currently when building LLEXT for Xtensa we use the -fPIC compiler
option, but this cannot be used when using detached sections in
extensions. Add a Kconfig option to switch between the two
compilation modes and switch -fPIC off when building relocatable
(partially linked) ELF binaries.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Adds compiler flag(s) and some architecture-specific relocations
for ARC. No userspace support, doesn't support all relocations.
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
In order to compile with C++ exception handling for xtensa, the libgcc
location needs to be known. This change uses the same logic from gcc's
target.cmake to query the compiler for libgcc location and add the lib
to the include list.
Signed-off-by: Mark Inderhees <markind@meta.com>
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>
Fix the following warnings:
[255/261] Linking C executable zephyr/zephyr_pre0.elf
lto-wrapper: warning: using serial compilation of 8 LTRANS jobs
lto-wrapper: note: see the '-flto' option documentation for more
information
[260/261] Linking C executable zephyr/zephyr.elf
lto-wrapper: warning: using serial compilation of 8 LTRANS jobs
lto-wrapper: note: see the '-flto' option documentation for more
information
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Following the footstep of GCC/Clang cmake code to remove
TOOLCHAIN_LIBS, xcc also has it removed and utilizes
something similar to c_library to link the HAL library.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
`arcmwdt`` and `clang` both have
`-Wno-missing-field-initializers` in `warning_dw_1` and
`-Wmissing-field-initializers` in `warning_dw_2` while `gcc`
has `-Wmissing-field-initializers` in `warning_dw_1`, so
update it to match.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.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>
Moving specs argument to compiler and linker properties so that the
compiler and linker in use can decide how the flags are mapped / handled
for the compiler and linker in use.
This avoids specifying `--specs=spec.picolibc` for clang which prints a
warning about an unused argument.
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>
This commit introduces architecture-specific ELF relocations for RISC-V,
in accordance with the RISC-V PSABI specification:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc
Also, the necessary compiler configurations for compiling LLEXT
extensions on RISC-V are added, and the llext tests are executed on
RISC-V targets.
Calling llext extensions from user threads in RISC-V is still
unsupported as of this commit.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
Adds support for all relocation type produced by GCC
on AARCH64 platform using partial linking (-r flag) or
shared link (-fpic and -shared flag).
Signed-off-by: Adam Wojasinski <awojasinski@baylibre.com>
The macro `toolchain_cc_nostdinc` were made obsolete with PR#24851 and
are no longer invoked.
Remove the macro implementations.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Don't provide __STDC_LIB_EXT1__ macro (Extensions to the C Library,
Part 1: Bounds-checking interfaces) if we use minimal libc - as we don't
have functions from this extension implemented in minimal libc.
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Clang uses floating-point instructions by default, even if -mfpu is not
defined. Disable using FPU when CONFIG_FPU=n.
Using floating-point instructions when FPU is not enabled generates
Usage Fault.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
