How to use Clang Static Analysis

[kurt]

In the VGDB settings, there is an option to enable Clang Static Analysis.  I’ve enabled it, but it doesn’t seem to do anything.  I couldn’t find any documentation about this in the manual and forum, so I hope someone can give me a primer on how it actually works.

Let me give you my setup, in case you can stop what is wrong:

• IDE:  VS2017
• VGDB 5.3 Preview 8
• C++ project uses cmake/ninja.

How I created my project:

• New Linux project
• Import a CMAKE project (“Advanced” option unchecked)
• Source code is located in Windows, and copied over to Linux VM for compilation
• gcc toolchain is used in the VM.

Further settings:

• IntelliSense Settings = “Use default per-user setting (Clang-based)”
• Code Analyzers = “Enable static code analysis”.

As an example, I have core.unitialized.Assigned checked.  Then, I wrote this code:

 int x;
 x |= 1;

The compilation passed, and I was able to deploy to my ARM target.  I was expecting a warning, or at least a squiggly line.

Is there an explicit command to perform the analysis?  Or is it doing nothing because my toolchain is gcc?

[support]

Hi,

The code analysis results are normally shown in the regular Errors pane (and are also highlighted in the code). They don’t interfere with the build and can be distinguished by the “[Clang IntelliSense]” prefix:

If they don’t appear for your project, please try creating a new project from scratch and see if this works. If yes, please try comparing project properties between the 2 projects.

Attachments:

You must be logged in to view attached files.

[kurt]

Thanks for the screenshot and letting me know it’s automated behavior.  It is working now.

While a bit off topic, I still have issues setting up Clang IntelliSense:

(1) From the posts in the forum, I understood that we have to put in the correct flags (-D<xxx>) for the parsing to work.  I might have to read up on Clang since I am using GCC… it’s a vague question, but any examples or tutorials for non-Clang users to reap the benefits for Clang IntelliSense will be appreciated.

(2) I am getting simple IntelliSense errors like “vector is not part of the std namespace”.  Ok, I understand that the library files are in the VM and not in Visual Studio/PC, so I need to let VisualGDB know about the paths.  So, under the “IntelliSense Directories” tab in the Settings, I clicked “Add Remote” and added all the paths in the remote VM, which includes my project’s source headers, the compiler headers (/usr/include/, /usr/lib/gcc), and the paths to my ARM toolchain.  I can see that IntelliSense errors related to missing functions from my project is now resolved, but I still face issues with the standard libraries (such as the vector example) and things like “unable to find size_t”.  What else do I need to do?

 

[kurt]

Ah, I’ve learned something new.

(1) In the “IntelliSense Directories” tab, I cannot just add a top-level directory and expect the system to traverse recursively … I will need to add each folder explicitly.  For

example:

<toolchain_root_folder>/usr/src/kernel/include
<toolchain_root_folder>/usr/src/kernel/include/linux

By manually adding these folders one-by-one, I am able to make the system find things like size_t, time_t, etc.

(2) The order in which I place these folders do matter.  For example, toolchain folders should be on top, while project folders should be below.

—————————–

Question:  Is there an easier way where I can just put define <toolchain_root_folder> and let change search recursively?

[kurt]

<span style=”text-decoration: underline;”>Problem with remote caching:</span>  My toolchain folder paths are long.  VGDB’s default RemoteSourceCache path is long too given it’s stored in AppData.  Some of the files couldn’t be copied, so that explains why Clang couldn’t find certain symbols.

Cannot create C:\Users\kurt\AppData\Local\VisualGDB\RemoteSourceCache\192.168.1.82\0000\usr\src\debug\gcc-runtime\6.3.0-r0\gcc-6.3.0\build.arm-company-linux-gnueabi.arm-company-linux-gnueabi\arm-company-linux-gnueabi\libstdc++-v3\include\bits\stl_iterator_base_types.h: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Q:  Is there a way to define where the remote cache is located?

I’m gonna try an alternative of copying the entire toolchain folder to Windows in a shorted path, and see if Clang can find it.

[support]

Hi,

Sorry, the remote source cache location is fixed and cannot be changed.

One quick workaround would be to try using the Advanced CMake Subsystem with the direct SSH file access. It will perfectly support long paths, duplicate case-sensitive names and other scenarios that don’t work on Windows.

Another option would be to indeed copy the toolchain directory somewhere locally and then use the header discovery mechanism to quickly locate the missing headers.

[Author]

Posts