c9804d24fe
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>
38 lines
2.0 KiB
CMake
38 lines
2.0 KiB
CMake
# Uniquely identify the toolchain wrt. it's capabilities.
|
|
#
|
|
# What we are looking for, is a signature definition that is defined
|
|
# like this:
|
|
# * The MD5 sum of the compiler itself. A MD5 checksum is taken of the content
|
|
# after symlinks are resolved. This ensure that if the content changes, then
|
|
# the MD5 will also change (as example toolchain upgrade in same folder)
|
|
# * The CMAKE_C_COMPILER itself. This may be a symlink, but it ensures that
|
|
# multiple symlinks pointing to same executable will generate different
|
|
# signatures, as example: clang, gcc, arm-zephyr-eabi-gcc, links pointing to
|
|
# ccache will generate unique signatures
|
|
# * CMAKE_C_COMPILER_ID is taking the CMake compiler id for extra signature.
|
|
# * CMAKE_C_COMPILER_VERSION will ensure that even when using the previous
|
|
# methods, where an upgraded compiler could have same signature due to ccache
|
|
# usage and symbolic links, then the upgraded compiler will have new version
|
|
# and thus generate a new signature.
|
|
#
|
|
# Toolchains with the same signature will always support the same set of flags.
|
|
#
|
|
file(MD5 ${CMAKE_C_COMPILER} CMAKE_C_COMPILER_MD5_SUM)
|
|
set(TOOLCHAIN_SIGNATURE ${CMAKE_C_COMPILER_MD5_SUM})
|
|
|
|
# Extend the CMAKE_C_COMPILER_MD5_SUM with the compiler signature.
|
|
string(MD5 COMPILER_SIGNATURE ${CMAKE_C_COMPILER}_${CMAKE_C_COMPILER_ID}_${CMAKE_C_COMPILER_VERSION})
|
|
set(TOOLCHAIN_SIGNATURE ${TOOLCHAIN_SIGNATURE}_${COMPILER_SIGNATURE})
|
|
|
|
# Loading of templates are strictly not needed as they does not set any
|
|
# properties.
|
|
# They purely provides an overview as well as a starting point for supporting
|
|
# a new toolchain.
|
|
include(${CMAKE_CURRENT_LIST_DIR}/compiler/compiler_flags_template.cmake)
|
|
include(${CMAKE_CURRENT_LIST_DIR}/linker/linker_flags_template.cmake)
|
|
|
|
# Configure the toolchain flags based on what toolchain technology is used
|
|
# (gcc, host-gcc etc.)
|
|
include(${TOOLCHAIN_ROOT}/cmake/compiler/${COMPILER}/compiler_flags.cmake OPTIONAL)
|
|
include(${TOOLCHAIN_ROOT}/cmake/linker/${LINKER}/linker_flags.cmake OPTIONAL)
|