-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Fix up native_sim for #89073 #90353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix up native_sim for #89073 #90353
Conversation
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 <Torsten.Rasmussen@nordicsemi.no>
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 <Torsten.Rasmussen@nordicsemi.no>
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 <Torsten.Rasmussen@nordicsemi.no>
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 <Torsten.Rasmussen@nordicsemi.no>
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 <Torsten.Rasmussen@nordicsemi.no>
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 <keithp@keithp.com>
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 <keithp@keithp.com>
This file was deleted and isn't used elsewhere. Signed-off-by: Keith Packard <keithp@keithp.com>
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 <keithp@keithp.com>
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 <keithp@keithp.com>
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 <keithp@keithp.com>
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 <keithp@keithp.com>
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
This just adds a patch to #89073 to try and get native_sim working.