Help needed, SonarQube7.4 analyze embedded C project failed!


(jeremy.xiang) #1

SonarQube Developer Edition:
build-wrapper: 5.1 (linux-x86)
SonarCFamily: 5.1.1 (build 10386)
embedded c compiler: powerpc-eabivle-gcc(4.9.4)
Host environment: Ubuntu 16.04.1 x86_64


I am now looking into the features of sonarqube-developer-7.4 and trying to make sure that it is suitable for us.
The evaluation key valid for 2 weeks already be installed.

I created a simple embedded C project to do analyze, but seems that it failed to produce the desired results.
I guess the build-wrapper didn’t catch those intermediate results. So that SonarQube scanner did not cover the C source file.

I have no idea what should do for a successful analyze. Any help will be greatly appreciated.

The operating environment and steps are as follows.

The project use MPC5748G which developed by NXP Company as the microprocessor and S32DS for Power V1.2 as IDE.

The contents of main sorce file main.c as follows, As you can see, it is very simply and have some obvious defects in it.

#include "derivative.h" /* include peripheral declarations */
#include <stdlib.h>
#include <string.h>
extern void xcptn_xmpl(void);
int main(void)
    volatile int counter = 0;
    xcptn_xmpl ();              /* Configure and Enable Interrupts */

    char *p = (char *)malloc(100);

    if(NULL != p)
     /* Loop forever */

I do analyze with the steps as follows:

First, I use the command below to produce intermediate directory:

build-wrapper-linux-x86-64 --out-dir ../bw-outputs make clean all

The source file can be compiled successfully using the makefile which is autogenerated by IDE. but I can’t find anything useful in ../bw-outputs/build-wrapper-dump.json.
The contents of output file build-wrapper-dump.json as follows:

# (C) SonarSource SA, 2014-2017,
# 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.

you can find log file build-wrapper.log as attachements.

Second,I run command below to do scanner:


The contents of scanner config file as follows:

sonar.projectName=Example of C/C++ Scan (with BuildWrapper)

the terminal output is sonar-scanner-terminal-ouput.txt as attachements.

Finally, I check the analyze result on webpage, the results are shown below:

sonar-scanner-terminal-ouput.txt (28.9 KB)

build-wrapper.log.txt (46.4 KB)

Any help will be greatly appreciated.

(Loïc Joly) #2

Hello Jeremy,

Your compiler is not supported by SonarCFamily.

You may be interested by this thread: Is there a way to deal with unsupported C compilers?

(jeremy.xiang) #4


I have performed the analysis as you suggested. The result is shown below.

however, I still have some questions.

  1. The powerpc-eabivle-gcc(4.9.4) is just a variant of the GCC, why it can’t be recognized by build-wrapper-linux-x86-64. Could you explain the concept of build-wrapper in simple way?

  2. When I run “sonar-scanner”, I get many “Parse errors” as below, what effect they have and how can I get rid of them?

    INFO: Using build-wrapper output: /tmp/sonarqube/build-wrapper-dump.json
    WARN: Parse error
    during analysis of compilation unit: /home/jeremy/work/proj/kilo-gw/gateway/MPC5748g/MPC5748g_Z4_0/src/Protocol_stack/FreeRTOS-Plus-TCP/portable/NetworkInterface/mpc5748g/NetworkInterface.c
    in file: /home/jeremy/work/proj/kilo-gw/gateway/MPC5748g/MPC5748g_Z4_0/src/Protocol_stack/FreeRTOS-Plus-TCP/include/FreeRTOS_IP.h
    at line: 138

    135: struct xMAC_ADDRESS
    136: {
    137: uint8_t ucBytes [ ( 6 ) ] ;
    138: }

  3. There are other “WARNS” as below, why are they appearing and how to fix?
    Does the “INFO: 0/407 files analyzed” has an impact.

    INFO: SCM provider for this project is: git
    INFO: 407 files to be analyzed
    INFO: 0/407 files analyzed
    WARN: Missing blame information for the following files:
    WARN: * common/include/diag_common.h
    WARN: * include/FreeRTOSConfig.h

Any help will be greatly appreciated.
Comment: Full log of sonar-scanner as the attachment.
scanner_log_1226.txt (995.6 KB)

(Loïc Joly) #6

Hello @jeremy,

Regarding your first question, the build wrapper tries to monitor all processes that are launched during the build, in order to check which of those are compilers, and save the compiler command line options.

In your case, you can see in the build wrapper log that programs such as echo, as or ld are detected, but not powerpc-eabivle-gcc (even if we see the process calling it, and a process called by it).

We are not sure exactly why. Most probably, powerpc-eabivle-gcc is a statically linked binary, and the build wrapper can not detect those…

One way to work around that, if you really want to make the build-wrapper work (but it is tricky and requires some work) would be to create a program (with a name ending by -gcc) that just runs powerpc-eabivle-gcc by transferring the same command line arguments, then adapt the makefile to run this program instead of directly running powerpc-eabivle-gcc. If this program is dynamically linked, as most programs are, then we should detect it…

Regarding your second question, I could not find the error you mentioned in the attached log. It’s hard to say exactly what happened without debug logs…

Anyways, we totally rewrote the CFamily analyzer front-end for the version 6.0 (bundled with SonarQube 7.5), and I would suggest you use this version to perform your test:

  • It may give more information in the log as to what is the error
  • The error might even no longer be there :slight_smile:
  • This would probably make more sense for your evaluation anyways…

For your third question, I see in the log, in the part related to the CFamily plug-in :

19:02:06.319 INFO: 398 compilation units analyzed

This is what really matters. The part with 0/407 is about detecting blame information. Since this part failed, the analysis results will not contain any SCM related information. But all issues will still be detected correctly.