Commit Graph

17 Commits

Author SHA1 Message Date
Patryk Duda
fad8ae4052 linker: Introduce linker-tool-lld.h
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>
2023-07-05 12:33:42 +00:00
Alberto Escolar Piedras
e9af821e22 cmake: Add partial linking abstraction
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>
2023-06-23 09:05:14 +02:00
Gerard Marull-Paretas
d0e58ad0a6 device: use iterable sections
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>
2023-05-12 12:01:10 +02:00
Daniel Leung
5d9079ba6d linker: ld: lld: do not do RELRO when using llvm/clang
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>
2023-03-29 19:48:47 -04:00
Daniel Leung
81c3b3152c cmake: linker: make passing -no-pie configurable
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>
2023-03-29 19:48:47 -04:00
Daniel Leung
41f015b39b linker: use find_package() to find LLVM lld
This introduces a new cmake module FindLlvmLld.cmake to do
the work to discover LLVM lld linker.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-03-29 19:48:47 -04:00
Daniel Leung
7864caba1b linker: llvm: provide a default config file for clang
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>
2023-03-29 19:48:47 -04:00
Flavio Ceolin
56ec06f344 kconfig: linker: Add --no-relax build option
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>
2023-01-16 11:20:32 +00:00
Christian Taedcke
1fde62ef35 cmake: linker: lld: add missing -no-pie flag
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>
2022-11-22 13:02:44 +09:00
Yuval Peress
fae9923ff2 unittest: update coverage library non gcc toolchains
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>
2022-11-21 16:09:46 -05:00
Chen Peng1
d8fa857b19 LLVM: add built-in lld linker support for x86.
add support to use LLVM built-in lld linker to build
zephyr applications for x86 platforms.

Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
2022-06-05 14:10:25 +02:00
Gerard Marull-Paretas
671067bd61 cmake: linker: lld: add missing -imacros flag
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>
2022-04-05 11:18:20 +02:00
Torsten Rasmussen
a199291ddc cmake: remove base_name for dep file
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>
2022-03-17 11:37:07 +01:00
Torsten Rasmussen
1fa3f15137 cmake: update configure_linker_script() to prepend -D on defines
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>
2021-11-08 20:45:07 +01:00
Torsten Rasmussen
c9804d24fe scripts: gen_handles.py: take device start symbol as argument.
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>
2021-08-30 08:54:23 -04:00
Anas Nashif
1bb4e71bf2 toolchain: add support Intel oneApi toolchain based on llvm
This adds preliminary support for the oneApi toolchain for X86. The
toolchain is available from here:

   https://software.intel.com/content/www/us/en/develop/tools/oneapi/base-toolkit/download.html

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2021-03-25 08:54:10 -04:00
Anas Nashif
1d949ee20f cmake: llvm: use lld
Use lld linker instead of ld.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2021-03-25 08:54:10 -04:00