-fuse-ld=lld is currently specified twice through the baremetal property
(in cmake/linker/lld/linker_flags.cmake) and TOOLCHAIN_LD_FLAGS (in
cmake/linker/lld/target.cmake). This doesn't really harm anything as
it isn't duplicated on the link line (and specifying it multiple times
wouldn't hurt even if it was), but it also doesn't really help anything.
-fuse-ld isn't baremetal-specific and setting it via TOOLCHAIN_LD_FLAGS
will cover this case anyway, so remove this duplicate.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Native builds uses system libraries per default.
Instead of handling this in each linker_libraries.cmake files, then the
check for native build is moved one level up and for native build a
dedicated linker_libraries_native.cmake is sourced.
This simplifies the linker_libraries.cmake files as they no longer need
to check for native builds.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The property based toolchain integration allows a cleaner design by
letting the toolchain define its properties and values and let CMake
implementation of Zephyr provided C and C++ libraries adjust those
properties when minimal C or C++ libraries are used.
This commit moves handling of C++ linker library properties into
the minimal C++ CMake implementation.
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>
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>
Move linker flag setting from toolchain_ld_baremetal() to linker flag
properties as to follow the principle used in previos commits and from
PR#24851.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Transition the linker flag for the toolchain_ld_base and
toolchain_ld_cpp macros to linker flag properties.
This work follows the toolchain abstraction started in PR#24851.
toolchain_ld_base() was intended for base linker flags, but has slowly
become a 'set-any-linker-flag-here' and thus having several
`if(<check>)` or `<func>_ifdef(<check> ...)`.
Move the check to the top-level Zephyr CMakeLists.txt file, so that it
becomes cleaner which part is responsible for setting a value, and then
move the actual value (the linker flag) definition to the linker flag
property location.
It also helps adding support for new linkers, as it becomes clearer
which linker flags Zephyr always expects, for example `base` and
`cpp_base`, as well as those settings which are targeting for a given
purpose, such as linker sort alignment.
It also makes it clearer when those are used, for example in top-level
CMakeLists.txt with CONFIG_LINKER_SORT_BY_ALIGNMENT compared to this
information being buried in a linker support macro.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The selection of the runtime library when using LLVM has already been
done in llvm/target.cmake and passed to the toolchain_ld_base() function
through the global TOOLCHAIN_LD_FLAGS setting.
The only reason this haven't been noticed is because of CMake's built-in
symbol de-duplication feature.
Remove the redundant runtime library handling.
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>
Unlike GNU ld, lld's gp relaxation is disabled by default and must be
explicitly enabled via `--relax-gp`. Pass this flag to enable gp relaxation
for lld when both linker relaxations and gp usage for RISC-V are enabled.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
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>
lld gained support for the --print-memory-usage flag somewhat recently
(May 2023). Associate this flag with the memusage property when building
with lld, similar to what is done for GNU ld.
Signed-off-by: Jonathon Penix <jpenix@quicinc.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>
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>
Until now, linker-tool-gcc.h was used when LLD linker was chosen.
This causes linking issues because for GNU LD we use ALIGN_WITH_INPUT
attribute which is not available in LLVM LLD.
When using GNU LD we have to use ALIGN_WITH_INPUT to make sure that the
difference between VMA and LMA remains the same between output sections
that have different memory regions for VMA and LMA (RAM and FLASH).
With ALIGN_WITH_INPUT it's safe to do the memcpy of sections
that needs to be copied from flash to RAM in one function call:
(from z_data_copy() in kernel/xip.c)
```
z_early_memcpy(&__data_region_start, &__data_region_load_start,
__data_region_end - __data_region_start);
```
By default, LLVM LLD aligns both VMA and LMA to the same value, but
when --omagic (-N) option is provided then only the first output section
of given region has aligned LMA and the difference between VMA addresses
(0 is this is the first section) is added.
As a result the difference between LMA and VMA is constant for every
section, so this emulates ALIGN_WITH_INPUT option present in GNU LD
(required by XIP systems).
The --omagic flag is defined in cmake/linker/lld/target_baremetal.cmake
Example:
```
MEMORY {
ROM : ORIGIN = 0x1000, LENGTH = 1K
RAM : ORIGIN = 0x11000, LENGTH = 1K
}
SECTIONS {
.text 0x1000 : {
*(.text*)
} >ROM
.data.rel.ro : {
*(.data.rel.ro)
} >RAM AT>ROM
.data : {
*(.data*)
} >RAM AT>ROM
}
```
```
echo '.globl _start; _start: nop; .byte 1;'\
'.data.rel.ro; .balign 16; .byte 0;'\
'.data; .balign 32; .byte 0;' | \
llvm-mc -filetype=obj -triple=arm - -o test.o
armv7m-cros-eabi-ld.lld --sort-section=alignment -N -T script.ld \
test.o -o lld_out
```
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000094 2**2
1 .data.rel.ro 00000001 00011000 00001010 000000a0 2**4
2 .data 00000001 00011020 00001030 000000c0 2**5
```
In this example the first section has lower alignment than the following
section, but with -N option the difference between VMA and LMA is the
same for .data.rel.ro and .data sections.
For comparison, using BFD linker with --omagic option results in the
following:
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000094 2**2
1 .data.rel.ro 00000001 00011000 00001005 000000a0 2**4
2 .data 00000001 00011020 00001006 000000c0 2**5
```
with ALIGN_WITH_INPUT added, GNU LD adds the difference between VMA to
LMA, but doesn't align LMA of .data.rel.ro section:
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000074 2**2
1 .data.rel.ro 00000001 00011000 00001005 00000080 2**4
2 .data 00000001 00011020 00001025 000000a0 2**5
```
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Add a property to abstract the partial linking/rellocatable
linking for gcc ld and llvm's lld.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@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>
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>
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>
In some architectures the linker performs global optimization relaxing
address modes and changing intructions in the output object file. This
is a problem when userspace is enabled since it assumes that addresses
won't change after certain build stage. In no supported architectures
this option is ignored.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
See also
https://github.com/zephyrproject-rtos/zephyr/pull/38903
This is required when building tests for native_posix on ubuntu 22.04 using
clang-14 from the normal deb repository.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
When building with clang, the unittests were giving us an error:
```
error: undefined symbol: llvm_gcda_start_file
```
This seems to be from linking in `gcov` regardless of the toolchain.
It appears that clang doesn't need any special library for coverage.
With this change the following now produce identical coverage reports:
```
$ ZEPHYR_TOOLCHAIN_VARIANT=zephyr ./scripts/twister -p unit_testing \
--coverage -i -T tests/unit/intmath/
$ ZEPHYR_TOOLCHAIN_VARIANT=host ./scripts/twister -p unit_testing \
--coverage -i -T tests/unit/intmath/
$ ZEPHYR_TOOLCHAIN_VARIANT=llvm ./scripts/twister -p unit_testing \
--coverage -i --coverage-tool lcov \
--gcov-tool $(pwd)/scripts/utils/llvm-gcov.sh \
-T tests/unit/intmath/
```
Signed-off-by: Yuval Peress <peress@google.com>
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>
