Fixes#64149
Add support for a new Kconfig symbol: BUILD_OUTPUT_ADJUST_LMA_SECTIONS.
This is supplemental to the existing BUILD_OUTPUT_ADJUST_LMA setting,
which normally adjusts all output sections' LMA by the provided offset.
Defining the new symbol will narrow down the set of applicable sections
to a user-specified CMake list of name patterns.
Example usage:
DT_CHOSEN_Z_FLASH = zephyr,flash
DT_CHOSEN_Z_SRAM = zephyr,sram
config BUILD_OUTPUT_ADJUST_LMA
default "$(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_FLASH)) - \
$(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_SRAM))"
config BUILD_OUTPUT_ADJUST_LMA_SECTIONS
default "*;!bss;!noinit"
Supported values for BUILD_OUTPUT_ADJUST_LMA_SECTIONS are aligned with
objcopy, since this feature has only been supported with GNU binutils
thus far.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
On very early stage build system needs to get access to DTC preprocessor.
MWDT has no it's own preprocessor, so here zephyr-SDK preprocessor is used.
On latest build stages zephyr-SDK objcoby also required as MWDT binutils
don't support all features. This at the same time requires that
ZEPHYR_SDK_INSTALL_DIR must be initialized with valid arch-dependent
prefix.
Zephyr-SDK requires ARCH variable to be initialized before
include "generic.cmake", but in hew HWMv2 model ARCH variable will be
initialized more later. This workaround uses any (first awailable,
independent on ARCH) toolchain from SDK for DTC preprocessing only.
For other build stages ARCMWDT will be used.
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
Minimize the amount of flags that are hardcoded in the llext.cmake
module by moving them to the compiler specific cmake files.
The llext.cmake module will now use the new LLEXT_REMOVE_FLAGS and
LLEXT_APPEND_FLAGS global variables to adjust the set of flags used
to compile the llext code. This will make it easier to add support
for new architectures and compilers.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
As of today MWDT toolchain in case of Zephyr may use few
tools from GNU toolchain - GNU compiler for DTS preprocessing
and objcopy for section renaming.
Currently we were trying to find any GNU compiler & objcopy
which start to cause compatibility issues for new targets -
i.e. not every objcopy knows new ARC targets.
Let's use ARC GNU tools from Zephyr SDK as we still usually
require it when building with MWDT for other tools like DTC
(device tree compiler)
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
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>
Fixes: #51821
Set CMAKE_STRIP using `find_program(CMAKE_STRIP strip)` to support
strip when building on native posix.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The commit c2419fc006 introduced a change
to the CMake toolchain detection routine in which it attempts to use
the distro-provided `gdb-multiarch` GDB executable when the target-
specific GDB executable cannot be found (i.e. fallback to
`gdb-multiarch`).
This can cause many problems for the Zephyr users because the distro-
provided GDB does not contain any Zephyr-specific patches and it may
misbehave under various conditions (e.g. negative tid/pid being
displayed, Xtensa debugging mysteriously failing, ARC debugging not
working).
This commit removes the fallback mechanism to the distro-provided
`gdb-multiarch` because it is better to display an error message saying
GDB is not found than to use a wrong GDB that can give out very
confusing and misleading error messages to users.
Moreover, this fallback mechanism is no longer necessary because the
Zephyr SDK is now available on all major host operating systems and it
provides the target-specific custom GDB that contains all Zephyr-
specific patches.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The Zephyr SDK 0.15.0 release has changed the default GDB executable to
be Python-less and introduced an alternate Python-capable variant
called `gdb-py` (note that the Zephyr SDK previously provided
`gdb-no-py` instead).
This commit updates the CMake toolchain detection routine to attempt
using the Python-capable GDB variant (gdb-py) first and, if it is not
available or fails to launch due to a missing libpython dependency,
use the Python-less GDB variant (gdb).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
On Debian, llvm-obj{copy,dump} tools are installed with a version
suffix. Look first for a version that matches our compiler when
probing for tool paths before trying the bare version, or falling back
to GNU binutils.
Signed-off-by: Andy Ross <andyross@google.com>
Fix for #47353 where we add and enable symbol generation,
but miss to add proper options for ARCMWDT toolchain.
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Optional way for generating symbols file using binutils. This file will
be generated on demand for tests which will then be parsed by twister to
create an accurate test plan from the listed testcase/suites.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
As Zephyr currently requires CMake version 3.20.0, update all
occurrences of cmake_minimum_required.
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
This commit adds support for adjust the addresses of the final image.
This is useful when the image is to be flashed at a location different
from the LMA address encoded in the ELF file by the linker.
An example use-case is multicore systems where core A might load image
from a flash partition into RAM in order for core B to execute and load,
but where the image itself is build with the RAM addresses as LMA.
It updates the zephyr_image_info.h header with information of adjustment
value.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The GDB check routine added in the PR #38749 does not suppress the
console outputs (stdout and stderr) and may print out a misleading
error message during a CMake configuration when the required version
of Python is not available on the system:
arm-zephyr-eabi-gdb: error while loading shared libraries:
libpython3.8.so.1.0: cannot open shared object file: No such file or
directory
This commit adds the `OUTPUT_QUIET` and `ERROR_QUIET` options when
executing the GDB process so that the console outputs during the GDB
executable validation are not displayed to the user.
In addition, this commit removes the unused `GDB_PY_NO_PY` standard
output redirection variable since it is unnecessary.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
GDB can be built with or without Python support. When built with Python
support this can cause a particular problem: The gdb executable relies
on shared libraries that are bound to a specific Python version. But
since most Linux distributions typically ship with a single version, it
is very difficult to choose which one to target when building GDB.
When GDB executes, if it fails to load the shared libraries it will exit
immediately with an error code of 127 and output resembling this:
/home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb:
error while loading shared libraries: libpython3.8.so.1.0: cannot open
shared object file: No such file or directory
There are two known approaches to shipping multiple gdb executables:
- The Zephyr SDK ships a default gdb with Python enabled, and then a
separate gdb-no-py executable with Python disabled
- GNU Arm Embedded ships with a default gdb with Python disabled, and an
additional gdb-py with Python enabled
To mitigate the problem of not being able to debug, fall back to a
'gdb-no-py' if it exists whenever the standard gdb executable fails to
even run.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Initial bintools support for elfconvert
- hex, srec, bin conversion
- strip
- gap fill
Initial bintools support for readelf
Initial bintools support for disaasembly
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
add .S file extension suffix into CMAKE_ASM_SOURCE_FILE_EXTENSIONS,
because clang from OneApi can't recongnize them as asm files on
windows, then they won't be added into build system.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
Some targets require *strip* command. This command was not
being set when selecting llvm toolchain.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Ensure > is an independent argument.
The ; will ensure that the `>` and `outfile` are given as two arguments
and thus ensure correct behavior in all cases.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit converts the MWDT bintools implementation from the old
macro based approach and into the new toolchain property scheme.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
* add metaware toolchain support in build system:
* compiler
* linker
* binutils
* gcc objcopy is used because it can't be replaced
with mwdt's binutils currently
* To use ARC metaware toolchain, you'd better:
* in Linux/Unix environment
* install arc gcc/zephyr toolchain to use gnu's objcopy
tool
* set ZEPHYR_TOOLCHAIN_VARIANT=arcmwdt
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
This command add support for `<command>_flag_final` to all bintools
commands.
This allows users that has special use-cases to use a CMake script
for bintool command execution, and thereby have full control of command
invocation and argument processing.
Example of how to specify the property for such use:
Calling a custom script for elfconvert command:
set_property(TARGET bintools
PROPERTY elfconvert_command ${CMAKE_COMMAND})
set_property(TARGET bintools
PROPERTY elfconvert_flag "")
set_property(TARGET bintools
PROPERTY elfconvert_flag_final -P elfconvert.cmake)
set_property(TARGET bintools
PROPERTY elfconvert_flag_strip_all "-DSTRIP_ALL=True")
set_property(TARGET bintools
PROPERTY elfconvert_flag_infile "-DINFILE=")
set_property(TARGET bintools
PROPERTY elfconvert_flag_outfile "-DOUT_FILE=")
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
As part of toolchain abstraction three template files to facilitate
additional toolchain support development has been introduced.
Those covers:
- bintools
- compiler flags
- linker flags
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
GNU/bintools abstraction completed.
The following commands and flags are now available in bintools:
- memusage
- elfconvert
- dissassembly
- readelf
- strip
The bintools template has now been updated with more description which
will be useful when adding support for more toolchains in future.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Added support for creating an assembly listing containing all sections
like rodata, data and debug sections, not just those expected to
contain instructions.
Signed-off-by: Rohit Gujarathi <gujju.rohit@gmail.com>
This abstracts the interface for generation of the strip command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the readelf command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objdump command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objcopy command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The method for getting a memory usage report printed during build, is
based on a GNU linker (ld) option flag, and thus is not necessarily
supported by other toolchain binary tools.
The introduced cmake macro allows for a given toolchain to specify how
the memory usage report is to be generated, and whether the command for
generation, if any, is to be added to the post_build_commands and the
post_build_byproducts lists of the top level CMakeLists.txt
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Grzegorz Swiderski