Hi Thomas,
1) If you can provide implementations in standard C, then yes, it can be a benefit
2) Yes, I think that would make the code review easier.
3) You are right, adding ifdefs to C files should not be the way to go. As GNUARM doesn't provide symbols like this, we could easily solve this problem by creating the symbols in the ld file to be the same as the ones generated by the ARMCLANG toolchain.
One option is to do the same for the EWARM toolchain as for GNUARM. I had a quick look at the EWARM Development Guide, and it seems that the linker configuration file supports this feature (exporting symbols, and using expressions with start/end addresses of elf sections).
Another way to go would be to move the REGION_DECLARE, REGION_NAME, and related macros to a compiler specific header file, like tfm_compiler.h. Then this file could be placed in the platforms' toolchain specific directories. This solution would have the benefit, that the multiple definitions of the macros would be reduced to a single one. However to me this seems to be a greater effort: - The build system have to be modified to add the platform specific folder as include folder for compilation - The macros should be restructured a bit, as there would be a need for LOAD_REGION_DECLARE(...), EXECUTION_REGION_DECLARE_RW(...), EXECUTION_REGION_DECLARE_RO(...) and more (at least based on my quick look at the code) - All the source files have to be updated to use the new macros and include the specific header
4) The way to solve this could be to create a new function in the Compiler<tooolchain>Common.cmake files, called something like get_pre_include_parameter, that generates the proper option (--preinclude of -include) and call that function in BuildMbedtls.cmake
Regards, Mate
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 04 February 2019 15:41 To: DeMars, Alan via TF-M tf-m@lists.trustedfirmware.org Subject: [Tf-m] Issues porting to new toolchain
Greetings,
I am working on adding IAR Embedded Workbench for ARM (EWARM) as a supported toolchain for TF-M and I would like to discuss some of the issues I've run into before I start issuing PR:s.
1) The current TF-M source uses non-standard gcc extensions which EWARM does not support.
I assume it should not be an issue converting this code into standard C, that would only help porting to other toolchains as well.
2) Should I create separate PR:s for these changes and the toolchain changes?
3) In some places (tfm_core.c, ...) there are hardwired references to symbols like Image$$TFM_UNPRIV_SCRATCH$$ZI$$Base, Image$$TFM_UNPRIV_SCRATCH$$ZI$$Limit. Our toolchain would use symbols like TFM_UNPRIV_SCRATCH$$Base and TFM_UNPRIV_SCRATCH$$Limit instead.
What to do about this? Adding #ifdefs in the .c files will be messy and I'd like some cleaner solution.
4) Some common cmake files contains hardwired option names like "-include" (BuildMbedtls.cmake)
Our toolchain uses "--preinclude" instead and I think this ought to be handled in the compiler specific cmake files instead.