IAR C‐STAT Static Analysis - iarsystems/cmake-tutorial GitHub Wiki
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.
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.
- 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>
isC
orCXX
.${CMAKE_IAR_CSTAT}
is a CMake internal variable that returns the full path to theicstat
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.
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.