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>
