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>
Currently, the linker that is used when performing various cmake checks
(check_c_compiler_flag, for example) may be different than the linker that
will be used during the actual build. This happens as we currently specify
'-fuse-ld' to force the appropriate linker a) after many such checks have
already happened and b) in a way which is not automatically propagated to
check_c_compiler_flag (and friends). As a result, the toolchain's default
linker will generally be used for such checks regardless of which linker
was selected in Zephyr.
This can lead to a number of surprises when building Zephyr, particularly
when building with clang. For example:
- If the linker is misconfigured, where the build will fail can vary
depending on whether the linker is the toolchain's default. When the
configured linker happens to be the toolchain's default, the build
(helpfully) fails quickly on the checks for a basic working toochain.
When the configured linker isn't the default, the build won't fail until
the final link steps.
- The build can fail due to issues with a linker other than the one
configured by the user in Zephyr. For example, LLVM toolchains without
lld will generally fail to build Zephyr (the checks for a basic
working toochain will fail) for targets where lld is the default in LLVM
even if GNU ld is configured in Zephyr and would otherwise be used in the
final build.
- Flags which are only added if check_c_compiler_flag (or similar) succeeds
may be unexpectedly omitted during the final build if the flag is
supported in the configured linker but is unsupported in the toolchain's
default linker (as check_c_compiler_flag will test using the default
one).
Note that this isn't limited to clang--even when we are building with
Zephyr's SDK and force ld.bfd, we seem to use the 'ld' variant during the
cmake checks (though this generally seems fairly harmless compared to
mixing ld/lld or other proprietary linkers).
To fix this, ensure the appropriate 'fuse-ld' is set early enough and in
such a way that the same linker will be used throughout the entire build.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Remove the toolchain_ld_<base|baremetal|cpp> macro as all the macro
handling is now done through the use of linker properties.
Keep support for calling the old macros for out of tree toolchains
which have not been updated to the new property approach.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The support of PROPERTY_LINKER_SCRIPT_DEFINES has been broken since
the transition to CMake in 12f8f76165.
The intention was probably to allow users / projects to adjust
PROPERTY_LINKER_SCRIPT_DEFINES by setting a CMake cache variable.
The implementation tests for the CMake variable (local scope or cache)
PROPERTY_LINKER_SCRIPT_DEFINES, but it never uses such CMake variable.
Instead it uses a CMake global property named
PROPERTY_LINKER_SCRIPT_DEFINES. CMake variables and CMake global
properties are two very different things, and therefore the current
implementation has never worked. The fact that no one has never noticed
this flaw, means that the feature has never been used as intended.
Simplify the code by removing the use of the global CMake property and
instead set the value of the property on the linker script
pre-processing invocation.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Differently from other libraries, which are included whole in the final
Zephyr ELF, libkernel.a itself isn't. Assuming this is intended to
enable optimisations (if it isn't, this patch will break things) - linker
can remove parts of the kernel that are not used by the application.
However, when considering Linkable Loadable Extensions (llext), this
optimisations can be counterproductive: for instance, syscalls that are
not used by the application won't be available for extensions. It won't
matter if someone "EXPORT_SYMBOL" for them, or even try to keep them
using LINKER_KEEP, they'll be gone.
To avoid that, this patches includes, when CONFIG_LLEXT=y, libkernel.a
inside the linker "whole-archive" block. This ends up making it consider
libkernel.a as a library whose all symbols should be kept. Note this
doesn't mean that all symbols will be there - things compiled out via
Kconfig will naturally still be out.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
LLVM toolchain provides its own C++ standard library called libc++.
This patch adds new LLVM_LIBCXX config which should be used to indicate
that libc++ is used.
Information about library can be found at https://libcxx.llvm.org
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Fixes: #35671
Add minimal version required for LLVM LLD linker.
Linking fails with older LLVM LLD, such as v10.0.0.
LLVM v14.0.0 was released in 2022, and latest LLVM is v17.0.1.
Zephyr currently doesn't have a strict minimum version of LLVM
specified, but based on LLVM development and known issues on older
releases, then a minimum version of v14.0.0 has been chosen in this
commit.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Use iterable sections to handle devices list. This simplifies devices
implementation by using standard APIs.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The autoconf.h macros were not passed to the CMake custom command for
linker script generation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
With CMake 3.20 relative path inside DEPFILEs are treated relative to
CMAKE_CURRENT_BINARY_DIR and are transformed by CMake in its internal
dep file.
Therefore Zephyr build system must no longer add `base_name` to the
`-MT` argument for the preprocessor.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Currently all calls to `configure_linker_script()` specifies `-D<name>`
when calling `configure_linker_script()`.
This works well for the gcc pre-processed ld linker script templates,
but Zephyr also supports a CMake linker script generator which can be
used for ld scripts and armlink scatter files.
In this case, a `-D` must be stripped.
This commit changes this so that Zephyr CMake build system calls
`configure_linker_script()` without `-D`.
Thus the `LINKER_SCRIPT` choice can decide how this information should
be passed to underlying linker script functionality, that is `-D` for
linker script template and CMake variable for the CMake linker script
generator.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The current gen_handles.py script uses linker defined symbols.
As preparation for support of more linkers the gen_tables.py now takes
the device start symbol as argument.
For example, armlink and ld uses different symbols.
With ld those can be named explicitly, but for armlink the linker
decides the names.
For ld, Zephyr defines: __device_start
For armlink, the symbol is defined as: Image$$<section name>$$Base
Therefore knowledge of the linker symbol to be used must be passed to
gen_handles.py so that the correct symbol can be used for locating
devices.
To support this change, the creation of the asm, compiler, compiler-cpp,
linker targets has been moved from target_toolchain_flags.cmake to
target_toolchain.cmake.
All linkers has been updated to support the use of the
device_start_symbol on the linker target.
List of linkers updated:
- ld
- lld
- arcmwdt
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
