IAR C‐STAT Static Analysis - IARSystems/cmake-tutorial GitHub Wiki

Introduction

Seamless integration of IAR C-STAT, our static analysis tool, was introduced in CMake 4.1. This enhancement allows static code analysis to be performed effortlessly, directly from the project specification in the CMakeLists.txt file.

Helpful Resources

Interactive example

A CMake project example is provided at examples/cstat:

Project files
callee.c
callee.h
caller.c
caller.h
CMakeLists.txt
main.c

The main goal of the code used in this interactive example is to exercise static analysis with C-STAT, while showing its detection capabilities under different rulesets, used in distinct scenarios.

Tasks

  • Build the project as detailed in the tutorial. Ensure it builds without errors or warnings, meaning it consists entirely of legal C code.
  • Now perform the following tasks on the CMakeLists.txt project file (click to show/hide answers):
TODO 1: Enable IAR C-STAT Static Analysis
set(CMAKE_C_ICSTAT "${CMAKE_IAR_CSTAT}")
  • Save the file and rebuild the project.

NOTES

  • Setting the CMAKE_<LANG>_ICSTAT variable will enable project-wide static time analysis that runs alongside the compiler for every source file when <LANG> is C or CXX.
  • ${CMAKE_IAR_CSTAT} is a CMake internal variable that returns the full path to the icstat executable.
  • The default ruleset manifest file (cstat_sel_checks.txt) is generated automatically and includes the standard checks (stdchecks), which represent what we consider the bare minimum ruleset for any embedded system project.
  • It is also possible to use the SKIP_LINTING property for selectively exclude specific source files from being analyzed by C-STAT, enhancing the efficiency and effectiveness of the analysis workflow.
TODO 2: Select the CERT C ruleset
execute_process(COMMAND ${CMAKE_IAR_CHECKS} --default cert
                WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
  • Save the file and rebuild the project.

NOTES

  • The CERT rules are more pedantic so expect additional diagnostics generated for this very same code base.
TODO 3: Select the MISRA C:2012 ruleset
execute_process(COMMAND ${CMAKE_IAR_CHECKS} --default misrac2012
                WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
  • Save the file and rebuild the project.

NOTES

  • The MISRA C rules are even more pedantic and restrictive so expect further diagnostics generated for this very same code base.
TODO 4: Perform link-time analysis when using the MISRA C:2012 ruleset

Link-time analysis is a C-STAT feature that distinguishes it from the herd. It can reveal inter-modular lurking violations that only become visible when linking the application's object files. Since it goes beyond co-compiling the modules individually, a workaround for performing link-time analysis is required, as per CMake 4.1.

# Link-time analysis with C-STAT
if (DEFINED CMAKE_C_ICSTAT OR DEFINED CMAKE_CXX_ICSTAT)
  get_target_property(target_type ${This} TYPE)
  if(target_type STREQUAL "EXECUTABLE")
    add_custom_command(
      TARGET ${This}
      POST_BUILD
      COMMAND ${CMAKE_C_ICSTAT}
        --db=cstat.db
        --checks=cstat_sel_checks.txt
        link_analyze -- ${CMAKE_LINKER} $<TARGET_OBJECTS:${This}>
      COMMAND_EXPAND_LISTS
    )
  endif()
endif()
  • Save the file and rebuild the project.

NOTES

  • A new violation was detected: [MISRAC2012-Rule-17.2_b]:Function 'callee' calls itself indirectly.
  • In the C-STAT Static Analysis Guide, you can find more information about the Rule-17.2 violation by searching for it.
  • Additionally, searching for 'This is a link analysis check' in the guide's Summary of Checks section will reveal which rules are analyzed at link-time.

Summary

This interactive example covered enabling static analysis for CMake projects, progressing from basic static analysis to full MISRA C compliance. It also demonstrated setting up key C-STAT options. For more details on its full range of features, refer to your product's documentation.

Related Articles

⚠️ **GitHub.com Fallback** ⚠️