cmake: Pass OPTIMIZATION_FLAG to linker too

[keith-packard]

The compiler may want to know the desired optimization level during linking, as when the compiler multilib configuration includes -Os as a selector.

[tejlmand]

Thanks for the cleanup.

It would be nice to get rid of -L<libgcc_dir>, but we should ensure there are no side-effects (can't remember in which cases this happend last time I looked at this).

A couple of code observations to be addressed in addition.

[tejlmand]

This could be problematic as not all linkers may support the same optimization flags for compilation and linking.

Linkers invoked through the compiler, such as ld invoked through gcc/clang, will work but linkers invoked directly may fail, such as armlink.

@RobinKastberg how will the IAR linker behave in this regard ?

[keith-packard]

Yeah, I'm not sure how to ensure this doesn't break other toolchains. We already assume the linker can cope with a bunch of compiler flags, and most appear to want LINKERFLAGPREFIX. We could let the compiler tell the top level to not include ${OPTIMIZATION_FLAG} in the linker options? That would at least provide a simple way to fix problems if they crop up?

[tejlmand]

We already assume the linker can cope with a bunch of compiler flags, and most appear to want LINKERFLAGPREFIX.

Do we ?
This is one reason why we have linker flags properties, so that each linker can translate a property name into a linker option for the linker in use, like this:

zephyr/cmake/linker/ld/linker_flags.cmake

Line 39 in cc28f50

set_property(TARGET linker PROPERTY lto_arguments -flto=auto -fno-ipa-sra -ffunction-sections -fdata-sections)

zephyr/CMakeLists.txt

Line 248 in 32229d0

add_link_options($<TARGET_PROPERTY:linker,lto_arguments>)

Or by setting the option in a specific compiler/linker combo cmake file, like gcc/ld:

zephyr/cmake/linker/ld/gcc/linker_flags.cmake

Line 14 in 32229d0

add_link_options(-gdwarf-4)

There could still be legacy occurrences left which have not been updated, but I guess that just means those have proved themselves to be working until now, but that doesn't mean we should introduce new ones.

The main problem at this line, is that you take a flag defined for the compiler, and assume it works for the linker.
It might work for some, but can't be guaranteed to work for all.
Ref:

zephyr/CMakeLists.txt

Line 214 in 3305ccf

get_property(OPTIMIZE_FOR_SPEED_FLAG TARGET compiler PROPERTY optimization_speed)

zephyr/CMakeLists.txt

Line 225 in 3305ccf

set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_SPEED_FLAG})

zephyr/CMakeLists.txt

Line 245 in 3305ccf

add_link_options(${OPTIMIZATION_FLAG})

[keith-packard]

I'm open to suggestions, but we have to find a way to get the complete set of flags necessary to specify the correct linker paths to the linker, and that includes a bunch of flags which are currently only passed to the compiler. We could create linker versions of all of these flags, but many of those are not specified using target properties today, so that would involve a fairly extensive change to existing projects.

Alternatively, we could create a linker function that took these compiler options and mapped them to appropriate linker options, filtering out those which weren't meaningful. A default function would discard all of them. Something like 'linker_add_compiler_options'?

[keith-packard]

I've reworked the second patch so that the computation of rt_library and lib_include_dir are delayed until the compiler flags are finished.

I renamed library_find_path to compiler_find_path and then placed the gcc/clang implementation of that along with a new function, compiler_set_linker_properties into cmake/compiler/target_template.cmake, which gets included just after cmake/linker/target_template.cmake from FindTargetTools.cmake.

With this, the values of lib_include_dir and rt_library are both uniformly computed using --print-libgcc-file-name. As lib_include_dir is already used in the linker, that will ensure that the -L flag continues to get passed along as before, but this time it will have a value computed using the whole set of compiler flags.

This refactoring let me remove a bunch of nearly identical code in the compiler target.cmake files.

[keith-packard]

It would be nice to get rid of -L<libgcc_dir>, but we should ensure there are no side-effects (can't remember in which cases this happend last time I looked at this).

Ok, I've discovered it's actually impossible for us to compute libgcc_dir correctly in this fashion because some of the critical compiler flags are only available in the INTERFACE_COMPILE_OPTIONS property which is a generator expression, and hence cannot be evaluated during the cmake run.

Things like -m32/-m64, various -mfpu flags and many flags used on arc targets will all affect the multilib path value, but are unavailable when computing the libgcc path. I'm kinda amazed this ever worked anywhere.

For libgcc/compiler-rt, it's pretty simple - we can figure out what the runtime library basename is and use just that, without attempting to include the directory name. That should work as we can probably assume that any compiler install will use the same library name for all multilib configs?

For crtbegin.o/crtend.o, the linker won't search along the paths for them, so we really need to compute the whole path name. And that means capturing the output of the compiler front-end with the full compiler flags evaluated at build time?

[keith-packard]

Ok, I've discovered it's actually impossible for us to compute libgcc_dir correctly in this fashion because some of the critical compiler flags are only available in the INTERFACE_COMPILE_OPTIONS property which is a generator expression, and hence cannot be evaluated during the cmake run.

I did the best I could -- elided any flags which contained generator expressions and used the rest for all of the computations. That appears to at least get the flags needed for native_sim to work. A more complete solution would involve pushing the flag computation into the actual build run, and that seems 'problematic' as we'd have to pull the result back into the build process and insert it into the compile commands. Possible with make, but I'm unsure that could even work with ninja.