This layer is designed to make it easy to add Coverity static analysis to your Yocto builds. It supports committing defects to a Coverity Connect server, as well as viewing them locally.

Current supported version: 2022.6.0

This layer uses the new BitBake override syntax and poky variable names, so it only supports the Kirkstone and Langdale releases of Yocto.

Coverity is a paid commerical product. You must have the appropriate license(s).

• Automatic integration with several kinds of recipes (CMake, qmake5, and image)
• Supports gcc and clang
• Automatically aggregates translation units across the entire BitBake task graph (i.e. if you are analyzing recipe A, which depends on B, C, and D, then assuming all four are setup to use Coverity, translation units from all four are factored into the analysis).
• Build capture is setscene optimized
• Easy export of defects to local .html files
• Supports comitting defects to Coverity Connect server
• Customizable stream name
• Detailed progress capture for cov-analyze

These instructions configure your Yocto build system to enable Coverity integration.

• To run analyses, you need the analysis license (it's typically a .dat file). Edit local.conf to indicate where your analysis license is:

COVERITY_ANALYSIS_LIC = "/home/user/licenses/coverity-analysis.dat"

• You must download the analysis tarball (from https://community.synopsys.com/s/downloads) yourself and host it somewhere that is accessible to your Yocto build. (Obviously, it should only be accessible inside your corporate intranet to users who are licensed to use it). The easiest place to host it is on the Coverity Connect server itself in the $SERVER_INSTALL_LOCATION\server\base\webapps\downloads directory.

  Currently, version 2022.6.0 is the supported version. So, you need to download cov-analysis-linux64-2022.6.0.tar.gz

  Then, in your local.conf (or in a layer/distro .conf if you choose), set SRC_URI:pn-coverity-native to the location of the tarball. For example:

# This example assumes you are hosting the tarball on the Coverity Connect server in "Downloads" as described above
SRC_URI:pn-coverity-native = "https://MY-COVERITY-CONNECT-SERVER.company.com:8443/downloads/cov-analysis-linux64-${PV}.tar.gz"

• You will also need to explicitly enable Coverity integration in local.conf (or in a layer/distro .conf if you choose):

COVERITY_ENABLE = "1"

• (OPTIONAL) If you want to commit defects to a Coverity Connect server then you also need to set the following variables in local.conf:

# NB: Commits only happen when you explicitly run the do_coverity_commit_defects task. This variable is an extra failsafe so end-users (who may just be interested in local analyses) don't accidentally commit to streams.
COVERITY_ENABLE_COMMIT = "1"
# You can generate an authentication key using the Coverity Connect interface. Click your name in the top-right corner, then click "Authentication Keys" in the dropdown
COVERITY_AUTH_KEY_FILE = "/home/user/path/to/key.txt"
COVERITY_SERVER_HOST = "MY-COVERITY-CONNECT-SERVER.company.com"
COVERITY_SERVER_STREAM = "my-stream-name"

Recommendation: set COVERITY_SERVER_HOST and COVERITY_SERVER_STREAM in a layer or distro conf. Set the other two variables in local.conf as necessary (e.g. on your build machine).

You might consider using separate streams for different projects. In this case, you can set COVERITY_SERVER_STREAM conditionally. For example:

# Here, product-1 and product-2 are assumed to be the name of different MACHINEs. 
COVERITY_SERVER_STREAM:product-1 = "product-1"
COVERITY_SERVER_STREAM:product-2 = "product-2"

At a bare minimum each recipe that you want to be analyzed needs to have this line added:

inherit coverity

Try adding that line and then running bitbake my-recipe -c coverity_export_defects. If it works then you're probably good to go. Otherwise, consult the sections below for variables you can set to change how coverity.bbclass works. The first thing to check is whether you need a different integration strategy.

The variable COVERITY_STRATEGY configures how coverity.bbclass attempts to integrate Coverity with your build. The available options are:

• auto - default, explained below
• cmake - overrides OECMAKE_C_COMPILER and OECMAKE_CXX_COMPILER
• fs-capture-js - runs Coverity in filesystem capture mode looking for .js files
• path-hijack - manipulates the PATH environment variable so that our special trampoline compiler scripts are used instead of the actual compiler (explained more below)
• analyze-only - only useful for image recipes (or other "aggregates") that don't actually build any source code themselves

When auto is used the strategy is calculated as follows:

• If the recipe uses CMake (i.e. inherit cmake), use cmake
• If the recipe uses qmake from Qt5 (i.e. inherit qmake5), use path-hijack)
• If the recipe is an image recipe, use analyze-only
• Otherwise, error

Makefile-based recipes are mostly untested, but should use the path-hijack strategy.

Here are some variables you may want to tweak (either on a per-recipe basis, or local.conf/distro/layer wide):

While Coverity documentation generally suggests using cov-build in "Build capture" mode, that is not feasible for BitBake/Yocto. BitBake spawns worker processes in a way that cov-build cannot follow. Even if it could follow, the analysis results would likely not be complete due to BitBake's optimizations such as setscene. Moreover, we are probably not interested in the analysis of every single dependency of the system anyway.

coverity.bbclass takes a more surgical approach. It uses cov-translate as described in section 3.3.3 of the "Coverity Analysis 2020.06 User and Administrator Guide".

At a high level, coverity.bbclass works by manipulating the build environment in such a way that instead of the actual compiler getting called, a special trampoline script is called. This trampoline script is a thin wrapper around cov-translate. cov-translate, behind the scenes, invokes the real compiler. It also records the arguments that were passed to the compiler.

Later on, during the do_coverity_build task, Coverity goes over what cov-translate emitted and produces its intermediate data that will later be fed into cov-analyze.

coverity.bbclass adds the following BitBake tasks to recipes:

The only tasks you should need to run manually are the last three.

Feel free to submit PRs!

If you encounter issues, submit them and I'll do my best to look at the failure (though I don't have unlimited time to troubleshoot integrations).

• Kernel recipes are not tested
• Doesn't yet support native and nativesdk recipes (do_coverity_configure will probably fail)
• Encryption when commiting defects is currently disabled (due a bug in a previous version of Coverity that I haven't re-tested yet to see if fixed)
• Port for committing defects is hardcoded to 9090

Copyright 2022 Agilent Technologies, Inc.

This layer is licensed under the MIT license.

This is not an official Agilent or Synopsys product. No support is implied.