Fix up native_sim for #89073 #90353
Open
Fix up native_sim for #89073 #90353
+437
−243
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit cleanup and improve the structure of target toolchain handling in Zephyr. With this commit FindTargetTools.cmake is now the entry point for loading toolchain CMake file for configuring the toolchain and its properties. The main target toolchain handling structure is now: - Load compiler, linker, bintools template properties. - Load actual target compiler, linker, bintools properties. - Load target compiler, linker, bintools target CMake files. Those are responsible for defining the actual CMake compiler settings, setting up linker invocation, etc. For highlevel toolchain verification, a new `zephyr_verify_toolchain` function has been introduced which invokes the compiler to check its working state. Some compiler and linker properties requires testing the flags by invoking the actual compiler or linker. This is done using `check_set_compiler_property` and `check_set_linker_property`. However such tests cannot be executed until CMake's `project()` function has been called. Therefore calls to those functions are defered until the basic toolchain has been verified using `zephyr_verify_toolchain`. This allows us to introduce the above structure and thereby cleaning up toolchain handling and improving the design. It also allows compiler and linker target CMake files to use compiler properties as they are now available at an earlier stage. Signed-off-by: Torsten Rasmussen <[email protected]>
Align the compiler optimization property names with their corresponding Kconfig settings, as example so the property name `size_optimizations` matches `CONFIG_SIZE_OPTIMIZATIONS`. Signed-off-by: Torsten Rasmussen <[email protected]>
Support choice handling for compiler property. Some compiler configuration in Kconfig is handled using choices, such as compiler optimization. The compiler infrastructure uses property values for handling compiler flag variations between compilers. This works well when describing the compiler but when having to apply flags based on a Kconfig choice selection it results in constructs like: > if(CONFIG_ENTRY_A) > zephyr_compile_options($<TARGET_PROPERTY:compiler,entry_a>) > elseif(CONFIG_ENTRY_B) > zephyr_compile_options($<TARGET_PROPERTY:compiler,entry_b>) > elseif(CONFIG_ENTRY_C) > zephyr_compile_options($<TARGET_PROPERTY:compiler,entry_c>) > ... which may even have to be repeated multiple times. Introduce a higher property name which can match the choice name and which support taking the currently selected property value, while still keep current infrastructure of the compiler defining property values for all flags. Function signature: > set_compiler_property([APPEND] PROPERTY <name> CHOICE <name>...) This allows the if construct above to be simplified to: > zephyr_compile_options($<TARGET_PROPERTY:compiler,<choice_name>) Signed-off-by: Torsten Rasmussen <[email protected]>
Support linker optimization properties. Allow the linker property to inherit the property values of the compiler when those are identical. Signed-off-by: Torsten Rasmussen <[email protected]>
The path to a library may be depending on optimization level. Therefor include compiler optimization level for gcc / clang. For gcc and clang, then the same optimization flags are used during linking and therefor the property from the compiler flags is used. Signed-off-by: Torsten Rasmussen <[email protected]>
With inclusion of the optimization flag into the multilib selection process, we cannot compute the compiler library path when the compiler's target.cmake is processed as OPTIMIZATION_FLAG is not computed until much later. Instead, add a function (compiler_file_path) which can be used to locate the appropriate crtbegin.o and crtend.o files. Delay computation of lib_include_dir and rt_library until after all compiler flags have been computed by adding compiler_set_linker_properties and calling that just before toolchain_linker_finalize is invoked. Place default implementations of both of these functions in a new file, cmake/compiler/target_template.cmake, where we assume the compiler works like gcc or clang and handlers the --print-file-name and --print-libgcc-file-name options. Compilers needing alternate implementations can override these functions in their target.cmake files. These implementations require that no generator expressions are necessary for the compiler to compute the right library paths. This mechanism is also used to take any additional compiler options and pass them to the linker using toolchain_linker_add_compiler_options. Signed-off-by: Keith Packard <[email protected]>
The compiler_rt_library function can't see the -m32 link option added in arch/posix/CMakeLists.txt which is required to correctly compute the path, so it gets the wrong answer. Instead of attempting to fix that, just let the toolchain sort out the path itself. Signed-off-by: Keith Packard <[email protected]>
github-actions
bot
added
area: Bluetooth
area: Toolchains
github-actions
bot
requested review from
57300,
abrodkin,
carlescufi,
cvinayak,
erbr-ot,
evgeniy-paltsev,
jeremybettis,
nashif,
nordicjm,
stephanosio,
tejlmand,
thoh-ot,
Tronil and
wopu-ot
This file was deleted and isn't used elsewhere. Signed-off-by: Keith Packard <[email protected]>
This mirrors the support in set_compiler_property. This can be used when some of the choices values also use check_set_compiler_property and are queued awaiting the call to zephyr_verify_toolchain. Signed-off-by: Keith Packard <[email protected]>
The compiler_flags values are set before the toolchain has been verified, which means the call to check_set_compiler_property checking -Og will be queued. By also using check_set_compiler_property when setting 'optimization', it will also be queued. When executed later, the debug_optimizations value will have just been set, so the optimizations setting will get the correct value. Signed-off-by: Keith Packard <[email protected]>
A couple of modules need to force speed optimization and were expecting that OPTIMIZE_FOR_SPEED_FLAG would be set. That's no longer true, so we need to fetch it from the compiler. Signed-off-by: Keith Packard <[email protected]>
The optimization value is no longer available in the INTERFACE_COMPILE_OPTIONS target property, instead we need to look in the compiler optimization property. Signed-off-by: Keith Packard <[email protected]>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This just adds a patch to #89073 to try and get native_sim working.