cancel
Showing results for 
Search instead for 
Did you mean: 

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

0x0BADCODE
Associate II

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.

11 REPLIES 11
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 II

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 II

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?..

I can confirm in 1.16.1 is bugged as hell but it seems at STM nobody uses the function if it's still in this state after 1 year (it was working before).

@st by the way - YES, we need the Cyclomatic Complexity (at least for formal customer reports / reviews).

So we considered to integrate an external checker if you will not improve the IDE integration and reporting soon. Maybe your integrated parser does a good job, but it is not worse to waste much time with it, until:

- we are sure that all functions are shown properly;

- sorting by "Function name" works fine. Would be great to select also not only "Location" as module name, but also sorted large project by full path (folders / libraries)

- "hide dead code" works correctly - in DEBUG and RELEASE. Normally linker already excludes unused functions and variables, unless marked with special attributes to keep in "RELEASE" optimization. So why that buggy checkbox - if your results are based on generated ELF file (and not by formal parser of sources);

- interactive IDE usage is fine to occasionally goto source location and rework it (or comment as reasonable implementation) but generating configurable report per project / folder (lib) - with editable settings e.g. min. complexity - would be necessary as well