Zephyr: Expand toolchain/SDK support

[nashif]

I think we have some confusion in the way we set an environment with SDKs, toolchains and host tools. Probably a good start is to define a few things first and agree on terminology:

• SDK: This is a complete development environment that includes toolchains, host tools and other components that might be related to one architecture or board, including Zephyr itself I would argue.
• Toolchain: A compiler and all associated tools and libraries that will allow us to build Zephyr,
  does not have anything related to Zephyr really, this can be very generic toolchain that we can
  download from a vendor, examples:
  
  
  
  • ISSM,
  
  
  • ARM embedded compiler,
  
  
  • upstream Clang+LLVM,
  
  
  • crosstools-ng,
  
  
  • etc.
  
  

• Host tools: All non-compiler tools that are needed to help with building the code or build
  documentation, can be part of an SDK, for example:

  • kconfig
  • gperf
  • DTS
  • etc.

• [ ] Toolchains discussed during Toolchain WG

  • Nordic: ARM CC6 (armclang), Segger Embedded Studio GCC fork (non GPL licensing is main driver). ARM arch
  • CC5 is popular for Cortex-M, but probably not realistic
  • IAR: partners and customers requesting IAR support for Zephyr. So far only ARM requests, but possibly RISC-V in future
  • ARM: Keil MDK for safety and CMSIS-Zone. IDE and compiler
  • Synopsys: Metaware (clang). ARC
  • Intel: ICC for Intel arch. Clang-based. XCC for Xtensa
  • All: Open source clang
  • TI: TI clang compiler

Right now we have those mixed up a little bit and we need to cleanup the structure.

Collection of issues related to general toolchain and tool support:

• [x] rename ZEPHYR_GCC_VARIANT to something more appropriate
• [ ] Improve host compiler support
• [ ] Upstream Clang Support
• [ ] Synopsys Metaware Support

[SebastianBoe]

Perhaps also cleanup/fix/test/document CROSS_COMPILE or at least document
how to use toolchains that are not supported upstream.

I suspect it's definition changed during the migration.

I think it is supposed to be able to point to a toolchain that Zephyr is not aware of (does not have a zephyr/toolchain-.cmake file) but I don't think this works today.

[nashif]

I think it is supposed to be able to point to a toolchain that Zephyr is not aware of (does not have a zephyr/toolchain-.cmake file) but I don't think this works today.

yes, this used to work fine with Kbuild if I remember correctly.

[wenhuizhang]

Not sure if my understanding if correct, in cmake files, CMAKE_C_COMPILER is signed as ${TOOLCHAIN_HOME}/bin/${CROSS_COMPILE_TARGET}- , this points to where the SDK (meta-zephyr-sdk) files are. The SDK files has patches for gcc compilers.

[marc-hb]

Host tools: All non-compiler tools that are needed to help with building the code or build
documentation, can be part of an SDK, for example: kconfig, DTS,...

FYI autoconf calls these "build tools", not "host tools"
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html

• Specifying a build-type that differs from host-type enables cross-compilation mode.
• target-type (rarely needed).

That's because autoconf, gcc and others consider "build, host and target" to be relative, not absolute.
https://mesonbuild.com/Cross-compilation.html

the typical mistake assumes that the terms build, host and target refer to some fixed positions whereas they're actually relative to where the current compiler is running. Think of host as a child of the current compiler and target as an optional grand-child.

I'm of course not expecting Zephyr and others to change their terminology but it helps to keep that "off-by-one" terminology difference in mind.

[mbolivar]

Removing my assignment

[cfriedt]

Just a note about the IAR compiler (in particular, because I caught that we're considering linking with gcc).
The IAR compiler can be set to include a number of options to reduce binary size in the final link. This produces a number of custom ELF sections in object files. GCC does something similar with -fdata-sections and -ffunction-sections, but the IAR implementation is incompatible. So linking with binutils could result in link failures / possibly unexpected runtime behaviour. Eventually, someone might patch binutils to support IAR custom sections, but the IAR options that generate these custom ELF sections should be disabled until then.
At least that was the case when I looked at it way back in ~2015.
There might be a specific option for IAR to ensure it is compatible with GNU toolchains.

[tejlmand]

@cfriedt Thanks for the hints. And happy to see you following this work.
And feel free to give input to upcoming toolchain related PR's, i'm sure you have high experience and can provide valuable feedback.

It is correct that first step is to get everything compiling, but i'm sure @TTornblom want Zephyr to be able to link using the IAR linker also.