Only include crtbegin.o and crtend.o when LIBGCC_DIR is defined.
Since LIBGCC_DIR is not defined when compiling for posix
architecture, crt{begin,end}.o cannot be referred to via
LIBGCC_DIR.
Also note that, when using llvm/clang, crt{begin,end}S.o are
automatically for native_posix which collide with symbols in
crt{begin,end}.o. So there is no point in making LIBGCC_DIR
available for native_posix under llvm/clang.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
GNU ld and LLVM lld both complain under C++:
error: section: init_array is not contiguous with other relro sections
So do not create RELRO program header.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a new linker property specifically for passing
"-no-pie" to linker. Older binutils' LD (<= 2.36) do not
support this flag and will behave erratically if set. It
would parse "-no-pie" separately as "-n" and "-o-pie",
which would result in the output file being "-pie"
instead of "zephyr*.elf". Moreover, LLVM lld does not
support -no-pie but --no-pie (note the extra hyphen).
By having no-pie as a linker property, we can pass
correct no-pie flag to these linkers (or none at all).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a new output variable to FindGnuLd.cmake to indicate
if ld.bfd is found. Since we now ask the compilers for their
preferred ld.bfd linker, it may not match using the existing
string equal test to ${CROSS_COMPILE}ld.bfd. So set the new
variable GNULD_LINKER_IS_BFD to true if ld.bfd, and use it to
pass an extra argument to compiler to make it use ld.bfd.
Signed-off-by: Daniel Leung <daniel.leung@intel.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>
This asks the clang if it has its own preference for ld.lld.
This is to mirror what we are doing to find GNU ld, and to
make sure we are using the linker clang is using.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This asks the compiler if it has its own preference for ld.bfd.
This is useful for LLVM (when CONFIG_LLVM_USE_LD=y) so we know
which linker clang is using.
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 introduces a new cmake module FindGnuLd.cmake to do
the work to discover GNU ld (of binutils).
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>
When checking that modules contain a file `modules/modules.cmake`,
the CMake file only actually checked for the existence of the module
root, not the `modules/modules.cmake` file inside of it.
Signed-off-by: Pete Dietl <pete.dietl@worldcoin.org>
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>
Add a new script, snippets.py, which is responsible for searching
SNIPPET_ROOT for snippet definitions, validating them, and informing
the build system about what needs doing as a result.
Use this script in snippets.cmake to:
- validate any discovered snippet.yml files
- error out on undefined snippets
- add a 'snippets' build system target that prints all snippet
names (analogous to 'boards' and 'shields' targets)
- handle any specific build system settings properly,
by include()-ing a file it generates
With this patch, you can define or extend a snippet in a snippet.yml
file anywhere underneath a directory in SNIPPET_ROOT. The snippet.yml
file format has a schema whose initial definition is in a new file,
snippet-schema.yml.
This initial snippet.yml file format supports adding .overlay and
.conf files, like this:
name: foo
append:
DTC_OVERLAY_FILE: foo.overlay
OVERLAY_CONFIG: foo.conf
boards:
myboard:
append:
DTC_OVERLAY_FILE: myboard.overlay
OVERLAY_CONFIG: myboard.conf
/my-regular-expression-over-board-names/:
append:
DTC_OVERLAY_FILE: myregexp.overlay
OVERLAY_CONFIG: myregexp.conf
(Note that since the snippet feature is intended to be extensible, the
same snippet name may appear in multiple files throughout any
directory in SNIPPET_ROOT, with each addition augmenting prior ones.)
This initial syntax aligns with the following snippet design goals:
- extensible: you can add board-specific support for an existing
snippet in another module
- able to combine multiple types of configuration: we can now apply a
.overlay and .conf at the same time
- specializable: this allows you to define settings that only apply
to a selectable set of boards (including with regular expression
support for matching against multiple similar boards that follow
a naming convention)
- DRY: you can use regular expressions to apply the same snippet
settings to multiple boards like this: /(board1|board2|...)/
This patch is not trying to design and implement everything up front.
Additional features can and will be added to the snippet.yml format
over time; using YAML as a format allows us to make
backwards-compatible extensions as needed.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Basic things needed to integrate the new 'snippets' feature into the
build system. The main CMake variable which controls snippets is
SNIPPET. It is a whitespace-or-semicolon-separated list of snippet
names.
- Add minimal new cmake module for processing snippets. This just has
basic infrastructure for processing a SNIPPET variable into
SNIPPET_AS_LIST, and warning the user if they try to change it too
late.
- Integrate the new module into the build system, via
zephyr_default.cmake
This is anologous to the shields and boards modules' boilerplate and
input variables.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The commit adds CONFIG_MCUBOOT_CMAKE_WEST_SIGN_PARAMS Kconfig
option to allow passing arguments to west sign.
The option is used to pass arguments that immediately follow
west sign in cmake invocations and replaces hardcoded
"--quiet" parameter, but defaults to the "--quiet" value to
keep current behaviour.
New Kconfig option allows to pass arguments to west sign
without modifying cmake/mcuboot.cmake.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
When we build for a SoC that has a cortex-m4 w/o a FPU that
utilizes CMSIS headers with armclang (like mec1501modular_assy6885)
we get the following warning:
modules/hal/cmsis/CMSIS/Core/Include/core_cm4.h:93:8: warning:
"Compiler generates FPU instructions for a device without
an FPU (check __FPU_PRESENT)" [-W#warnings]
#warning "Compiler generates FPU instructions for a device
without an FPU (check __FPU_PRESENT)"
Fix the by setting -mfloat-abi=soft for such cases that don't have FPU
enabled.
Fixes#56068
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Moves the deprecation notice for prj_<board>.conf files to the
proper location where other deprecation notices are located.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
_static_thread_data should be in ROM as its static data. So move
it from common-ram.cmake to common-rom.cmake and fix it the params
we call zephyr_iterable_section with.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
This now throws an error if there is no prj.conf file located in a
user-specified APPLICATION_CONFIG_DIR, which otherwise would have
used an empty configuration and not included board-specific files.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
When building with C++ the icx compiler will try to utilize optimized
versions of memset/memcpy that are provided as part of libirc. However
libirc also has dependencies on things likes getenv/setenv, etc that
are expect in a linux host environment. So disable use of libirc
via compiler flag -no-intel-lib=libirc.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
This commit provides a number of helper macros for verifying arguments
passing to function:
- zephyr_check_flags_required
- zephyr_check_arguments_required
- zephyr_check_arguments_required_all
- zephyr_check_flags_exclusive
- zephyr_check_arguments_exclusive
which facilitates checking whether a required argument or flag has been
given or if mutual exclusive arguments are given.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit extends the Zephyr module yaml scheme with additional
entries for sysbuild in the build section.
This allows for Zephyr modules to extend the sysbuild infrastructure
by providing additional CMake and Kconfig files to be included in
sysbuild.
The new settings are:
build:
sysbuild-cmake: <path>
sysbuild-kconfig: <path>/<file>
sysbuild-ext: <true>|<false>
sysbuild-kconfig-ext: <true>|<false>
those settings follow the same pattern as the equivalent Zephyr build
settings but are processed by sysbuild.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Rename internals variables to lower case to distinguish those
variables from variables intended to be globally available.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Different users of the Zephyr CMake package may have different minimum
required versions of west. One important in-tree example is the
documentation, which must either be built with the latest version of
west, or with no west installed at all.
Make the MIN_WEST_VERSION variable configurable to support use cases
like this.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
CMake versions <3.20.5 contains the following bug:
https://gitlab.kitware.com/cmake/cmake/-/issues/22310
This bug was fixed in CMake 3.20.5:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6232
Generally Zephyr can build with CMake >=3.20.0, however the
`cmake/package_helper.cmake` is impacted by the above issue.
Therefore, specifically request CMake >=3.20.5 for package helper
and update documentation to recommend CMake version 3.20.5 in order
to minimize risk of users being impacted by this bug.
Users invoking package helper with CMake 3.20.0-3.20.4 will see:
> CMake Error at cmake/package_helper.cmake:45 (cmake_minimum_required):
> CMake 3.20.5 or higher is required. You are running version 3.20.x
Rest of Zephyr still builds with CMake versions >=3.20.0.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #55490
Follow-up: #53124
Prefix local version of the return variable before calling
`zephyr_check_compiler_flag_hardcoded()`.
This ensures that there will never be any naming collision between named
return argument and the variable name used in later functions when
PARENT_SCOPE is used.
The issue #55490 provided description of situation where the double
de-referencing was not working correctly.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
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>
This improves the version checking for the zephyr SDK by searching
for newer versions that the version that was detected. This works
around the issue whereby the versions are contained in files with
MD5 hashes which might be in any order.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Follow-up: #53124
The PR#53124 fixed an issue where the variable `check` was not properly
dereferenced into the correct variable name for return value storage.
This was corrected in 04a27651ea.
However, some code was passing a return argument as:
`zephyr_check_compiler_flag(... ${check})`
but checking the result like:
`if(${check})`
thus relying on a faulty behavior of code updating `check` and not the
`${check}` variable.
Fix this by updating to use `${${check}}` as that will point to the
correct return value.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
New C++ versions have deprecated "register" variables and restricted
"volatile" semantics, so new gcc's will emit warnings when they see
that syntax. Zephyr uses both in our C headers (though we should
probably get rid of register and unify with C++'s volatile model), so
we're disabling the resulting warnings.
But OLD gcc variants (like xcc, sigh) don't understand new -Wvolatile
and -Wregister on the command line, so they get confused. Limit the
uses to the standard versions for which gcc would emit warnigns; xcc
doesn't support those anyway.
Signed-off-by: Andy Ross <andyross@google.com>
Fixes: #53124
Fix de-referencing of check and exists function arguments by correctly
de-referencing the argument references using `${<var>}`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The toolchain support was developed and tested against arm clang
version 6.17. So add a check to ensure we are utilizing 6.17 or
newer.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Improve comments, rearrange variable definitions to better match the
control flow of the module, and avoid nesting by adding a return()
statement.
No functional changes expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
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>
Add a new UF2 runner, supporting only the flash capability.
Searches for FAT partitions containing `INFO_UF2.TXT` files,
and can optionally filter on a matching `Board-ID` value in
that file.
Signed-off-by: Peter Johanson <peter@peterjohanson.com>
Unlike gcc, clang splits out the flag controlling warnings about the return
type of `main' from other warnings related to that function. Add the extra
-Wno-main-return-type flag to mask these warnings when building Zephyr
without -ffreestanding, as when using picolibc.
Signed-off-by: Keith Packard <keithp@keithp.com>
This removes the enforced `-s` option and only passes in a `-gdb` only if
CONFIG_QEMU_GDBSERVER_LISTEN_DEV is set. When unset, it allows users to
utilize QEMU_EXTRA_FLAGS from environment preventing a clash that occurs
if `-s` and `-gdb` are both passed to QEMU invocation.
Signed-off-by: Alp Sayin <alpsayin@gmail.com>
Move extra warning option from generic twister script into
compiler-dependent config files.
ARCMWDT compiler doesn't support extra warning options ex.
"-Wl,--fatal-warnings". To avoid build fails flag
"disable_warnings_as_errors" should be passed to twister.
This allows all warning messages and make atomatic test useles.
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
nostdinc_include flag needs to contain path to llvm libraries
and remove other relative paths. Change compiler flag to add
default C includes on building C++ code using xcc-clang compiler.
Fixes#54730
Signed-off-by: Aastha Grover <aastha.grover@intel.com>
This avoids a cryptic DTC failure when compiling trying to compile
native_posix with a missing gcc or clang.
REQUIRED is available since CMake 3.18
Example with clang, cryptic error without this commit:
```
ZEPHYR_TOOLCHAIN_VARIANT=llvm west build \
-p -b native_posix samples/hello_world/
-- Found toolchain: host (clang/ld) <= this is wrong
-- Found Dtc: /usr/bin/dtc (found suitable version "1.6.1", minimum ...
-- Found BOARD.dts: zephyr/boards/posix/native_posix/native_posix.dts
CMake Error at /zephyr/cmake/modules/dts.cmake:191 (message):
command failed with return code: No such file or directory
Call Stack (most recent call first):
zephyr/cmake/modules/zephyr_default.cmake:113 (include)
zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boil...
CMakeLists.txt:5 (find_package)
```
Well hidden behind the scenes, dts.cmake fails above because it invokes
`CMAKE_C_COMPILER-NOTFOUND`
With this commit:
```
ZEPHYR_TOOLCHAIN_VARIANT=llvm west build \
-p -b native_posix samples/hello_world/
-- Found toolchain: host (clang/ld) <= this is still wrong
CMake Error at zephyr/cmake/compiler/clang/generic.cmake:7 (find_program):
Could not find CMAKE_C_COMPILER using the following names: clang
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Clang does not have printf return value optimizations like GCC, so there's
no flag to turn them off when building against a non-standard printf
implementation (e.g., picolibc without float support).
Signed-off-by: Keith Packard <keithp@keithp.com>
Deprecate old sparse support as Zephyr now provides a proper
infrastructure for SCA tools. Set ZEPHYR_SCA_VARIANT to sparse if user
is using deprecated way.
This allows to cleanup sparse code in various places and thus have a
cleaner build system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Sparse support was original introduced in #43776.
This commit introduces sparse support as part of Zephyr SCA tool
infrastructure.
The implementation in this commit has some benefits over existing
support:
- It does not required users to set `REAL_CC` in environment before
invoking build command.
This reduces risk of user mistakes, such as
- REAL_CC being different from CMAKE_C_COMPILER.
- User running CMake in one terminal / environment where REAL_CC is
defined but invoking the build command in a different terminal /
environment where REAL_CC is not defined or defined differently.
- It improve user experience as the user no longer has to define /
re-define REAL_CC when building for different architecture, like
switching from arm to xtensa, as this is now handled in CMake.
- CMAKE_C_COMPILER is not overwriting, this can be important for other
tools which calls the C compiler for pre-processing purposes, such
as devicetree and linker script generation.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Static code analyser (SCA) tools are important in software development.
CMake offers built-in support for some tools, such as cppcheck and
clang-tidy.
Other tools, such as sparse, are not directly supported.
This commit provides a uniform way for users to specify a supported
SCA using `ZEPHYR_SCA_VARIANT=<tool>` which is consistent with how
toolchains are specified.
ZEPHYR_SCA_VARIANT can be set using `-D` or in environment.
Support for an SCA tool is done in `cmake/sca/<tool>/sca.cmake`.
SCA_ROOT can be used to specify additional search paths when looking up
implementation for a tool. SCA_ROOT can also be specified in
`zephyr/module.yml` as setting. This makes it possible to provide SCA
tool implementation as part of a Zephyr module.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
