SonarQube and Segger Embedded Studio

cpp

(Vojtech Vladyka) #1

Hello,

I am having trouble with getting Sonar Qube working together with Segger Embedded Studio builder emBuild.exe. It seems that wrapper is not able to produce any outputs. Log is fine but json is rather empty:

# (C) SonarSource SA, 2014-2017, info@sonarsource.com
# All SONARSOURCE programs and content are copyright protected.
# SONARSOURCE and SONARQUBE are trademarks of SonarSource SA. All rights are expressly reserved.
#
# This file is designed exclusively for use with the SONARSOURCE C / C++ / Objective-C Plugin.
# It may not be used in connection with any other software.
# Any other use is prohibited by law and may be grounds for immediate termination of your License.
{
"version":0,
"captures":[
]}

Any ideas what to do to get it working with SES? Thanks.
Vojtech


(Nicolas Bontoux) #2

Hi Vojtech,

Compilers supported by the SonarQube C/C++ analyzer are listed here (Supported Compilers, Language Standards and Operating Systems).

I have no knowledge whatsoever about Segger Embedded Studio , however one sure thing is that if the underlying compiler does not fall into one of the supported compiler families, then the behaviour you report here is expected (and what you’re looking after is a #suggestions ).


(Vojtech Vladyka) #3

Thanks for reply.

Underlying compiler is GCC or LLVM, but it is encapsulated by emBuild.exe which is acting as make.

Regarding #suggestions, it would be definitely nice to have since SES is recommended tool by Nordic Semiconductor for their nRF chips.


(Evgeny Mandrikov) #6

Build system (whether it is make, ninja, nmake, msbuild, scons, bazel, gradle, just bash or cmd, or whatever else) is mostly doesn’t matter for build-wrapper. What really matters - is compiler used under the hood and its invocation from build system.

While we support various derivatives of GCC and Clang, there are corner cases. For example AFAIK there was absolutely no problems with GCC from Android NDK. For opposite example there is WindRiver compiler based on GCC, however changes in build-wrapper were required for recognition of this compiler as GCC. For another example there is ArmClang compiler based on Clang, but it manifests itself differently than Clang and in some cases even behaves differently, so changes were required in both build-wrapper and plugin.

Based only on documentation seems that Segger Embedded Studio is indeed, as you say, based/uses GCC and Clang. JSON is completely useless in cases when compiler is not recognized, while log is quite useful, so please provide file build-wrapper.log (file next to json) to help us understand why compiler is not recognized as GCC or Clang.


(Vojtech Vladyka) #7

Understood.

In my setup, whole thing is run from batch file:

:: SONARQUBE-PATH = path to folder with build-wrapper-win-x86-64 and sonar-scanner
SET SONARQUBE-PATH=%1
:: BUILDER-PATH is where IAR is installed used for building, C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\common\bin\IarBuild.exe
SET BUILDER-PATH=%2
:: SDK_ROOT
SET SDK-ROOT=%3

%SONARQUBE-PATH%\build-wrapper-win-x86-64.exe --out-dir bw-outputs  %BUILDER-PATH% -config "Release" "pca10040\s132\ses\dali_bms_sensor_s132.emProject" -echo -verbose -D SDK_ROOT=%SDK-ROOT%
%SONARQUBE-PATH%\sonar-scanner-3.1.0.1141-windows\bin\sonar-scanner -X

Build-wrapper.log is this (some files were build before, some were build by wrapper) is here: build-wrapper.log.txt (34.9 KB)

Complete log from cmd is attached.log.txt (125.4 KB)

Thanks for assistance.


Add support for cc1.exe in build-wrapper?
(Evgeny Mandrikov) #8

Seems that there is inconsistency between what you provide as content of “batch file” - “IAR”, topic of discussion and content of logs - “SEGGER”. I’ll assume that discussion is still about “SEGGER”, log is correct, while “batch file” is unrelated/typo.


Typical usage/interaction with GCC by build-system or by user happens via executables gcc or g++, so called “driver”, which in his turn uses other executables, in particular cc1, so called “frontend” that is not intended to be used directly by user. And so build-wrapper recognizes “driver” and ignores “frontend”.

According to your log: emBuild.exe doesn’t use “driver” and executes “frontend” cc1.exe directly, what perfectly explains why JSON is empty - this is simply not supported.

According to content of “SEGGER Embedded Studio for ARM 3.40” they even don’t provide GCC “driver”, only “frontend”. We can consider changing build-wrapper and plugin to rely on invocation of cc1 “frontend” instead of “driver”. But this wasn’t in our short/mid-term plans and for sure requires testing and some development, which volume might grow depending on results of testing, so can’t promise/guarantee/estimate this right now.

However they also provide Clang, thus could you please try it instead of GCC?


(Vojtech Vladyka) #9

Yes, it is still related to Segger, not IAR. Sorry for stray comment in batch file.

Anyway, I understand your point. I would be really happy if support will be added but thing is I need it working somehow right now. Either way, thanks for info.

Clang is supported by Segger but not by used SDK (nRF SDK by Nordic Semi), so this is not way to go.

Thanks for trying.


(Vasile Adrian Constantin) #10

My company also uses the compiler from Segger (and I can see cc1.exe being skipped in build-wrapper log) and Windriver also.

Has there been ance changes to support these please ?


(Nicolas Bontoux) #11

Hi Vasile,

Please avoid double-posts, you did the right thing in posting this suggestion:


(Evgeny Mandrikov) #12

(Evgeny Mandrikov) #13

To know about changes on this subject and save time by avoiding need to ask question and wait for answer, you can simply watch (subscribe to changes) on this ticket - https://jira.sonarsource.com/browse/CPP-2060