CMake linker generator and MPU_ALIGN #86563
bjorniuppsala
started this conversation in
RFC
Replies: 2 comments
-
There is now a working implementation of this in bjorniuppsala/iar-zephyr-fixes@953b7bb |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am working to make CMake linker generator able to work together with CONFIG_USERSPACE.
In that there is an on problem that is a bit more complicated, and I would very much appreciate some input on how to solve.
The problem is how to transfer and combine information from the original cmake-invocation and the analysis of intermediary linking steps.
Most of this is simple, #85241 I have added two ways to define input to the linker generator:
As an example these two are used to handle KOBJECT_DATA_SZ like so:
In the main CMake machinery (CMakelists.txt & cmake/linker_scripts/arm/linker.cmake)
When the linker generator runs it picks up the
#defines
from the .h file, and uses them to to replace the@var@
(The "undef:" thing allows us to have the same definition in the linker passes where the information is not yet available).In the ld-scripts it is handled with an
#include "linker-kobject-prebuild-data.h
and running the c-preprocessor.The thing that complicates matters is that e.g. MPU_ALIGN requires more expressive power than straight variable substitution.
For arm/cortex_m MPU_ALIGN is defined like (from include/zephyr/arch/arm/cortex_m/scripts/linker.ld):
For other targets the content varies, but the observation that we need input from both the main cmake machinery (the def of MPU_ALIGN) and the analysis steps (expression for the region_size) needs to be combined by the linker generator. For the ld-script skeletons this is accomplished by using the c-preprocessor. This is not feasible for the linker generator since it generates at least three varying file-formats (ld-script, scatter files and IAR icf files, all of which would require different handling).
My idea to handle this is to allow "recursive @-variable expansion". Meaning that when we would keep evaluating @foo@ as long as its value contains other (defined) @-variables. Together with allowing to define new variables as parameters inside the @-expression:
@FOO,region_size=end-start@
would solve this problem.Edit:
With my proposal, the above defintion of MPU_ALIGN moves to cmake/linker_script/arm/linker.cmake
And when using it:
Is this a reasonable approach ? The @-expression "language" gets somewhat more complicated, somewhere we still need a cmake-file to define the body of MPU_ALIGN. This may be done either directly in the main cmake-machinery, or by including a defintion at linker generator time.
One possible alternative might be to allow any cmake expression inside of the @'s. This comes with complications of how to handle return values from cmake-functions though.
Beta Was this translation helpful? Give feedback.
All reactions