IAR: Regression in 3.21.0, unable to compile project

I have a project which uses the IAR compiler, using a toolchain file.

With CMake version 3.20.5, this compiles without problems. After updating to CMake 3.21, it fails with the following error:

-- Check for working C compiler: C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe - broken
CMake Error at C:/Users/BDOMI/scoop/apps/cmake/3.21.0/share/cmake-3.21/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/DIST/dev/topas_core_2/build/topas_rel/CMakeFiles/CMakeTmp

    Run Build Command(s):C:\qp\qtools\bin\make.exe -f Makefile cmTC_d8493/fast && C:/qp/qtools/bin/make  -f CMakeFiles\cmTC_d8493.dir\build.make CMakeFiles/cmTC_d8493.dir/build
    make[1]: Entering directory 'C:/DIST/dev/topas_core_2/build/topas_rel/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_d8493.dir/testCCompiler.c.o
    C:\PROGRA~1\IARSYS~1\EMBEDD~1.0\arm\bin\iccarm.exe  --silent C:\DIST\dev\topas_core_2\build\topas_rel\CMakeFiles\CMakeTmp\testCCompiler.c  -IC:\PROGRA~1\IARSYS~1\EMBEDD~1.0\arm\inc\c --cpu Cortex-M4 --fpu VFPv4_sp --vectorize --no_wrap_diagnostics --mfc  -e -o CMakeFiles\cmTC_d8493.dir\testCCompiler.c.o
    Linking C executable cmTC_d8493.elf
    C:\Users\BDOMI\scoop\apps\cmake\3.21.0\bin\cmake.exe -E cmake_link_script CMakeFiles\cmTC_d8493.dir\link.txt --verbose=1
    C:\qp\qtools\mingw32\bin\ld.exe --silent CMakeFiles/cmTC_d8493.dir/testCCompiler.c.o --inline --merge_duplicate_sections  -o cmTC_d8493.elf
    C:\qp\qtools\mingw32\bin\ld.exe: unrecognized option '--silent'
    C:\qp\qtools\mingw32\bin\ld.exe: use the --help option for usage information

The problem seems to be that the wrong linker is used.

The correct linker for IAR would be C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/ilinkarm.exe, which is also found in the CMakeCache.txt file. However, the error message shows that CMake tries to use the C:\qp\qtools\mingw32\bin\ld.exe linker, which is not correct.

Are there any changes in the toolchain file necessary when updating to version 3.21?

CMakeOutput.log CMakeError.log

changed title from Regression in 3.21, unable to compile project using IAR to IAR: Regression in 3.21.0, unable to compile project

added comp:iar triage:regression labels

changed milestone to %3.21.1

Cc: @jean-marc.hengen.zuehlke

IAR is totally maintained by external contributors, and no one is running nightly testing with it. There have been some IAR-related contributions since 3.20 that are in 3.21.

added triage:mr-welcome label

Hi,

I'm pretty sure that this issue was triggered by using the <CMAKE_LINKER> placeholder in the IAR linker rule. Before using the placeholder a CMAKE_IAR_LINKER variable was used (and the placeholder will use the value of the CMAKE_LINKER variable if I'm not wrong). I was not seeing an issue since Modules/Compiler/IAR.cmake actually sets the CMAKE_LINKER variable:

set(CMAKE_LINKER "${CMAKE_IAR_LINKER}" CACHE FILEPATH "The IAR linker" FORCE)

(And testing with my local project everything seemed working as expected.)

I noticed in the report that the error occurred while detecting the compiler. I tried to reproduce the bug and could trigger an similar behavior when invoking CMake for the first time in an empty binary directory:

cmd.exe /C "cd . && CMAKE_LINKER-NOTFOUND --silent CMakeFiles\cmTC_915ec.dir\testCXXCompiler.cxx.o --basic_heap --semihosting   -o cmTC_915ec.elf && cd ."

I guess the CMAKE_LINKER variable was not set yet when testing the compiler. Invoking CMake a second time will succeed. I'm sorry for not noticing this earlier.

I will dive deeper into this issue and try to come up with a solution.

Short update: When CMake is run on a new binary directory with an IAR toolchain the following steps are executed (using the trace feature):

1. Modules/CMakeFindBinUtils.cmake is invoked first. It cannot find the IAR linker and will set something (e.g. C:\qp\qtools\mingw32\bin\ld.exe for the reporter and CMAKE_LINKER-NOTFOUND in my case).
2. Next Modules/Compiler/IAR-FindBinUtils.cmake is invoked which will find the IAR linker (as CMAKE_IAR_LINKER).
3. Later Modules/Compiler/IAR.cmake is invoked which will overwrite CMAKE_LINKER with set(CMAKE_LINKER "${CMAKE_IAR_LINKER}" CACHE FILEPATH "The IAR linker" FORCE).
4. Later Modules/CMakeTestCXXCompiler.cmake is invoked where try_compile is called. For some reason it will use the initial value for CMAKE_LINKER. This is where my analysis continues. Note I added the following lines in Modules/CMakeTestCXXCompiler.cmake right before try_compile:

   ...
    "int main(){return 0;}\n")
   message(DEBUG "CMAKE_LINKER @ try_compile: ${CMAKE_LINKER}")
   message(DEBUG "CMAKE_LINKER in cache @ try_compile: $CACHE{CMAKE_LINKER}")
   try_compile(CMAKE_CXX_COMPILER_WORKS ${CMAKE_BINARY_DIR}
     ...

   which shows the expected values:

   -- CMAKE_LINKER @ try_compile: C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.4/arm/bin/ilinkarm.exe
   -- CMAKE_LINKER in cache @ try_compile: C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.4/arm/bin/ilinkarm.exe

At some point I was thinking that we might have a scope issue (e.g. something like set(CMAKE_LINKER ${CMAKE_LINKER} PARENT_SCOPE) was missing) but doesn't seem so. I will continue my analysis.

Thanks. For reference, switching the linker rule to the <CMAKE_LINKER> placeholder was done in !6322 (merged) as a fix to !6092 (merged) for IAR and #22395 (closed).

Can the logic from Modules/Compiler/IAR-FindBinUtils.cmake be moved to Modules/CMakeFindBinUtils.cmake? The latter already has several toolchain-specific searches.

Cc: @lorcap

Thanks @brad.king for pull me into this issue report I wasn't aware of. I upgraded my ArchLinux box today and the problem popped up as described.

I confirm the problem has its roots in !6322 (merged). As a workaround, repeating set(CMAKE_LINKER "${CMAKE_IAR_LINKER}" CACHE FILEPATH "The IAR linker" FORCE) in the toolchain file temporarily fixes the issue.

I'll try following your suggestion tomorrow morning and see if we can get rid of Modules/Compiler/IAR-FindBinUtils.cmake.

@lorcap I was too late notifying your message and I was already working on a proof-of-concept. So you might want to take a look at my patch - I rebased it onto your branch: jean-marc.hengen.zuehlke:issue_22312

The good news is that moving the logic from Modules/Compiler/IAR-FindBinUtils.cmake to Modules/CMakeFindBinUtils.cmake solves this issue. In my proof of concept, I decided to add an extra path for the IAR toolchain. Since the IAR compiler creates elf binaries (on ARM, RX, ...), one could argue that a GNU objdump works perfectly fine for those files and we should extend the else clause.

There is one point I don't like about my patch: The Modules/Compiler/IAR-FindBinUtils.cmake also searches for some other tools (CMAKE_IAR_ELFTOOL, CMAKE_IAR_ELFDUMP, CMAKE_IAR_OBJMANIP, CMAKE_IAR_SYMEXPORT). I kept the logic for those tools inside Modules/Compiler/IAR-FindBinUtils.cmake which effectively duplicates the search logic. CMAKE_IAR_ELFDUMP might be candidate for CMAKE_OBJDUMP but their command line options are incompatible (compared with GNU objdump).

@brad.king How should I proceed? Should the tools stay in Modules/Compiler/IAR-FindBinUtils.cmake or also moved to Modules/CMakeFindBinUtils.cmake?

Appendix: IAR extra tools descriptions

name	description
CMAKE_IAR_ELFTOOL	The IAR ELF Tool, ielftool, can generate a checksum on specific ranges of memories. This checksum can be compared with a checksum calculated on your application.
CMAKE_IAR_ELFDUMP	The IAR ELF Dumper for Arm, ielfdumparm, can be used for creating a text representation of the contents of a relocatable or absolute ELF file
CMAKE_IAR_OBJMANIP	Use the IAR ELF Object Tool, iobjmanip, to perform low-level manipulation of ELF object files.
CMAKE_IAR_SYMEXPORT	The IAR Absolute Symbol Exporter, isymexport, can export absolute symbols from a ROM image file, so that they can be used when you link an add-on application.

@jean-marc.hengen.zuehlke, your patch is much more than welcome. Thanks a lot. I tested it in my environment and it works like a charm. Actually, I rebased your work on my other merge request !6357 (merged) and it applies without conflicts.

IMHO, all IAR tools should be moved to Modules/CMakeFindBinUtils.cmake. Even the all-other-cases else clause defines extra tools, such as ddltool or addr2line, which are meaningless for MS C/C++ compiler.

The Modules/Compiler/<id>-FindBinUtils.cmake modules are mostly used for CMAKE_<LANG>_COMPILER_{AR,RANLIB}, used for LTCG/IPO support. For the main linker and archiver, Modules/CMakeFindBinUtils.cmake should find them for all toolchains.

I don't feel strongly about the IAR extra tools. Either place is fine unless one doesn't work.

@jean-marc.hengen.zuehlke I merged !6362 (merged) (on which you based your fix for this) to the 3.21 release branch. Please rebase your change on the upstream release branch (e.g. commit 31ecd3718047874b5eeb939e9608fa1bd386c1a7), rename your topic branch to iar-binutils, and open a merge request.

I will do as requested.

@brad.king I prepared a final version of my patch (see !6372 (merged)). Is there any test suite I could run for IAR (on ARM) to ensure that no use case is missing this time?

@lorcap I would have a better feeling if my patch was tested on another environment than mine.

My patch removes a CMAKE_${_CMAKE_PROCESSING_LANGUAGE}_COMPILER_CUSTOM_CODE variable which was set in Modules/Compiler/IAR-FindBinUtils.cmake since we are using CMAKE_LINKER and CMAKE_AR (which is handled by default). I saw no use in continuing adding CMAKE_IAR_ELFTOOL, CMAKE_IAR_ELFDUMP, CMAKE_IAR_OBJMANIP, CMAKE_IAR_SYMEXPORT to CMakeCXXCompiler.cmake but I might be wrong.

At current commit e32f202d21, I believe Modules/CMakeDetermineASMCompiler.cmake needs some tweaks. When compiling my project I get the following during the generation phase (IAR's assembler is named iasmarm.exe):

…
-- The ASM compiler identification is unknown
-- Found assembler: /mnt/c/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe
-- Warning: Did not find file Compiler/-ASM
…

When invoking cmake with --debug-find I get:

…
CMake Debug Log at /usr/share/cmake-3.21/Modules/CMakeDetermineCompiler.cmake:50 (find_program):
  find_program called with the following settings:

    VAR: CMAKE_ASM_COMPILER
    NAMES: "/mnt/c/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe"
    Documentation: ASM compiler
    Framework
      Only Search Frameworks: 0
      Search Frameworks Last: 0
      Search Frameworks First: 0
    AppBundle
      Only Search AppBundle: 0
      Search AppBundle Last: 0
      Search AppBundle First: 0
    NO_DEFAULT_PATH Enabled

  find_program considered the following locations:

  The item was found at

    /mnt/c/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe

Call Stack (most recent call first):
  /usr/share/cmake-3.21/Modules/CMakeDetermineASMCompiler.cmake:42 (_cmake_find_compiler)
  boot_flasher/CMakeLists.txt:13 (project)
  boot_flasher/CMakeLists.txt:61 (add_boot_flasher)
…

I didn't have this warning before.

I will try to reproduce this on my setup. Until now, CMAKE_ASM_COMPILER was set in our toolchain file. Removing it from there should let fail our project (which I use as test ground).

Removing CMAKE_ASM_COMPILER from our toolchain file exposed the error found by @lorcap but the error occurs independent from my patch (in my test environment). Actually I queried the CMake repository (with git grep -i iasm) and the IAR assembler is never set. So I assume that the assembler is set somewhere in Lorenzo's project. It might be that the error from Lorenzo is triggered by my patch since it introduces a new elseif block in Modules/CMakeFindBinUtils.cmake whereas before the general else block was used.

It is hard to debug this without the context (since my test environment does not expose the same behavior) and just looking at the code, everything seems OK. I shared our toolchain file, maybe comparing it with others might reveal the detail required to reproduce the error. I have an additional platform file (Platform/Generic-IAR-CXX-STM32H743VIT6.cmake) setting CMAKE_CXX_FLAGS_INIT & friends. The remaining part of the project does not reference IAR since we compile the project with multiple compilers.

Any hint on how to proceed is welcome.

Does the error occur with CMake 3.20.5?

I repeated my test for CMake 3.20.5 and I get the same result (e.g. -- Warning: Did not find file Compiler/-ASM if I remove CMAKE_ASM_COMPILER from our toolchain file).

Thanks. In that case the problem is not part of the 3.21 regression, and so is outside the scope of this issue and of !6372 (merged). For now the workaround is to set CMAKE_ASM_COMPILER in the toolchain file. One could open a separate issue to track it.

mentioned in merge request !6362 (merged)

mentioned in merge request !6357 (merged)

mentioned in merge request !6372 (merged)

closed with commit 5b9bfe73

closed with merge request !6372 (merged)