Code Coverage for CMake Build

[Waleed]

Hi! I’m trying to use VisualGDB to generate a coverage report of the code under test as part of the build process with CMake. The “build code coverage reports” checkbox is enabled in project properties which adds the following to the CMakeLists.txt:

bsp_configure_code_coverage(ENABLED 1)

The build fails during the pre-link patching stage, where the pre-link.bat script is executed. This batch script gets generated as part of the build process and it’s quite large (approximately 304,235 characters) because it contains all the object files compiled in the project.

My initial assumption is that, since VisualGDB invokes the pre-link step through cmd.exe, the generated batch script may be exceeding the maximum command-line length which causes part of the command to get truncated, resulting in the observed build failure. However, I’m not certain whether this is the actual cause. If this is true, what would be the recommended workaround? If not, what is the most likely cause of the pre-link patching failure?

Any guidance or suggestions would be greatly appreciated. Thanks in advance!

I’ve attached a screenshot as well captured during build to show failure logs.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This could indeed be caused by the command-line length limit. VisualGDB’s code coverage support relies on patching all object files before the final linking takes place. This is defined in the coverage.cmake file under the VisualGDB\BSP directory:

add_custom_command(TARGET ${target_name} PRE_LINK COMMAND "$ENV{VISUALGDB_DIR}/VisualGDB.exe" ARGS /decover $<TARGET_FILE:${target_name}> ${_effective_sources})

If the _effective_sources list gets too long, it could indeed cause problems.

We can easily update VisualGDB to support the response file syntax (target name @<source list file>), but we are not aware of a straight-forward way to force CMake to use it for custom commands. You can try patching the CMake file on your end using temporary workarounds (e.g. manually generate a temporary list). If it works, we can easily upload an updated VisualGDB build with support for the @-syntax in that command.

[Author]

Posts