cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE 1.13.2: cyclomatic complexity reports all C++ as dead code

0x0BADCODE
Associate

I tried to analyze our mixed C/C++ STM32F4xx project, but all functions in *.cpp sources including "main()" are not shown by default, until I deactivated the "hide dead code" checkbox.

ST,

could you please confirm the bug in new Cyclomatic Complexity tool?

Hiding unlinked code would be useful indeed, if all actually called C++ functions would be reported correctly.

7 REPLIES 7
Semer CHERNI
ST Employee

Hello @0x0BADCODE 

First let me thank you for posting and apologize for the late reply.

I made a test and I'm not able to reproduce the described behavior.

Could you provide some code snip which help the see the issue?

KR,
Semer.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

0x0BADCODE
Associate

Hello Semer,

I just noticed today that the Cyclomatic Complexity window is empty - until I actually connect the target with Debugger (which is a bit surprising as I would expect the CC is a kind of static analysis tool, so having ELF image on host PC should be sufficient to track unused code, etc.).

So back to your question: if you cannot reproduce the behavior - it is not about a specific "code snip" but the debug configuration. In my case I use Segger JLink Plus or also Segger OB reflashed on Nucleo board. Moreover, with  debugger and Breakpoint set on RESET vector, the CC window is initially empty until the C main() is reached, then the C functions appear in the CC list but none of the C++... Hope this helps.

Hello @0x0BADCODE 

"I just noticed today that the Cyclomatic Complexity window is empty - until I actually connect the target with Debugger (which is a bit surprising as I would expect the CC is a kind of static analysis tool, so having ELF image on host PC should be sufficient to track unused code, etc.)."

> You are right only the elf file is needed for the feature to function and it's unusual to see the described behavior.

However, about the original question, after further test I see what you are talking about. Initially I misunderstood the question. I thought you talk about function declared with extern "C"  not the class methods.
I fact I imported a CPP project I found that methods declared in a class will not be shown unless the "Hide dead code" is ticked.
I will escalade this question internally and go back to you with an answer ASAP.

KR,
Semer.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

TonyM
Associate II

Same here.  I am on Cube 1.15.0 and none of my class methods in any of my *.cc files show until I deactivate that "Hide dead code" option.  At least that workaround exists.

I'm on 1.16.1 and despite "hide dead code" is unchecked, I can't see Cyclomatic Complexity.

The only way is to download in debug mode to the physical microcontroller

Is it a bug?

brokenagain
Associate

On version 1.16.0 it seems to work if you click  on the Cyclomatic Complexity tab then click on the yellow refresh button in the corner.

brokenagain_0-1732483730425.png

 

 

I am on 1.16.0 (the 1.16.1 looks irrelevant changes to my used MCUs) and behavior is the same as reported a year ago. Just in case: I am on Ubuntu 22.04.4 LTS (but I would expect the IDE behavior is same on all platforms).

- Cyclomatic complexity remains empty (also after yellow refresh button) until I select the debug session with related ELF image (just rebuild project, etc. does not help);

- with checked "Hide dead code" it only reports *.c sources; with unchecked also the *.cpp

- moreover, even sorting (by clicking on "Location / Function / Complexity) works ugly:

   - when sorted by "Location" I see e.g. 10 members of particular class in the list;

   - when sort by "Fucntion" I can find its constructor in one place of the list, few members returning "bool" type in other place, some more members return type "void" in next place, etc.

 Are you serious guys?!.. Why including the function return type as the part of the name when sorting by? Who would be interested to analyze the cyclomatic complexity (or whatever else) classified by return types as criteria - rather then by classes or modules?..