Skip to content

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

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

keith-packard
Copy link
Collaborator

This just adds a patch to #89073 to try and get native_sim working.

tejlmand and others added 7 commits May 16, 2025 11:25
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]>
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]>
@github-actions github-actions bot added the area: X86 x86 Architecture (32-bit) label May 22, 2025
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants