[Waleed]

Since the VisualGDB build is failing when code coverage is enabled with bsp_configure_code_coverage(ENABLED 1) and thus no ELF binary being generated, I had to divide it into steps:
1. Build the default application with code coverage disabled and save the resultant binary in separate folder temporarily.
2. Then, rebuild the application with code coverage enabled which will give me the response file with relative paths of object files. I replaced the relative paths with their absolute ones.
Finally, I ran the VisualGDB command manually with absolute path to the ELF and specifying response file with @-syntax, yet received no coverage information (screenshot-1). The same output is observed when the command is run inside decover.bat script.

As mentioned in your third point, what echo commands should I include in the batch? Could you please mention them here?

In addition, there’s one other workaround that I tried with this. The coverage.cmake file was located in the installation directory, and I edited its functionality to use response file rather than _effective_sources list. The new CMake command now looks as follows:

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

The ${rspfile} is the absolute path to the response file and the @-syntax is deliberately absent here because VisualGDB was giving error about not supporting this format. With this, and code coverage enabled in CMakeLists.txt, the build ran and one of the object files got detected at linking step after which it failed when there were issues e.g. memory overflow, undefined reference etc. found with it. I’m sure that this is not a problem with my existing application code. The complete logs for this build are captured in GDB-build.log. Could you please review them and let me know if anything stands out?

I’ve followed docs and made sure all the configuration is set accordingly. It would also be very helpful if you could share a working example of code coverage with a CMake-based project, including the generation of a coverage report. That would help me verify whether I’m not missing something.

• This reply was modified 23 hours, 45 minutes ago by Waleed.

Attachments:

You must be logged in to view attached files.

[Waleed]

Sorry I forgot to add the screenshots with my previous reply. They’re attached with this one.

Attachments:

You must be logged in to view attached files.

[Waleed]

I have updated VisualGDB version using your provided link. However, this version still doesn’t seem to work with the @-syntax command when I run it in cmd. The results are captured in screenshot-1.
Furthermore, according to your last statement, I really don’t understand how replacing the CMake custom command would help me in troubleshooting the issue. I went ahead and changed it in CMake like this:

add_custom_command(TARGET ${target_name} PRE_LINK COMMAND cmd.exe ARGS /c echo VisualGDB.exe /decover "${CMAKE_CURRENT_SOURCE_DIR}/build/VisualGDB/Debug/${target_name}" @${target_name}.rsp WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/build/VisualGDB/Debug/CMakeFiles
)

It ran the build successfully and just echoed the command back in console as expected (screenshot-2). The response file here is being generated with the build and doesn’t get deleted because I have passed -d keeprsp arguments to the ninja.

[Waleed]

I’ve looked for the coverage.cmake file but it’s not present at the specified path i.e. AppData\Local\VisualGDB or even its subdirectories. However, acting upon your suggestion, I manually created a text file containing all the object files, put them into a CMake variable EFFECTIVE_SOURCES and then referenced them with the @-syntax in CMake with command below. The rest of the settings for code coverage i.e. instrumentation, were removed temporarily.

add_custom_command(TARGET ${target_name} PRE_LINK COMMAND VisualGDB.exe ARGS /decover ${target_path} "@${EFFECTIVE_SOURCES}")

This time, the build completed successfully. However, it appears that VisualGDB did not execute the pre-link command, which suggests that the object files may not have been patched (screenshot-1).

For debugging, I ran the CMake command directly on cmd.exe, passing it the variable referencing limited number of object files but received no coverage information there (screenshot-2). Additionally, I’ve noticed that there is no /decover option to VisualGDB I’ve got installed (version 6.1R2 – build 5524), yet it’s not reporting any type of error when run with it apparently.

• This reply was modified 1 week ago by Waleed.

Attachments:

You must be logged in to view attached files.

[Waleed]

The issue was with test thread initialization, and I’ve moved on from this problem since. I’m now facing the issue of running tests on hardware. When I try to execute tests by entering into Debug mode in VisualGDB, it stops with a “Debugging Failed” popup, expecting an assembly manifest. I also tried it manually with the script below on CMD, yet it fails again to run any test. The tests are already being discovered, but the scheduled test vector isn’t being read.

VisualGDB.exe /runtests EmbeddedProject-Debug.vgdbsettings /platform:Hardware /config:Debug /targetPath:..\FW_FAM_W_RC-nrf52840ble-os.elf /vsoutput:report.trx

Attachments:

You must be logged in to view attached files.

[Author]

Posts