[cfe-dev] scan-build on RTEMS (try #1)

[Joel Sherrill]

  On 09/20/2010 12:28 PM, Ted Kremenek wrote:
> Hi Joel,
>
> In the output from scan-build, did you see any output that looked like:
>
>    ANALYZE: ....
>
> This is an indicator that the analyzer is analyzing a specific function in your code.
Not in that run.  I tinkered a bit and managed to get output
with some issues on the plane today.  Using the --use-cc
and --use-c++ options improved things.  After a normal
configure of RTEMS to target sparc/sis (simulator in gdb),
I ran this.

scan-build -o ${OUTPUTDIR} --experimental-checks \
   --use-cc ${RTEMS_TARGET}-gcc \
   --use-c++ ${RTEMS_TARGET}-g++ \
   make

where RTEMS_TARGET was sparc-rtems4.11

This handled part of RTEMS but it appears there are a few clang issues
preventing it from being able to analyse all of the RTEMS source.

The first is this which looks like a quoted string on the command
line is getting mangled:

/usr/lib/clang-analyzer/scan-build/ccc-analyzer  
-DPACKAGE_NAME=\"rtems-c-src\" -DPACKAGE_TARNAME=\"rtems-c-src\" 
-DPACKAGE_VERSION=\"4.10.99.0\" -DPACKAGE_STRING=\"rtems-c-src\ 
4.10.99.0\" -DPACKAGE_BUGREPORT=\"http://www.rtems.org/bugzilla\" 
-DPACKAGE_URL=\"\" -DCPU_U32_FIX=1 -I. 
-I/home/joel/rtems-4.11-work/build/rtems/c/src/optman  
-I../../../sis/lib/include   -mcpu=cypress -O2 -g -Wall 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT 
rtems/no_timer_rel-no-timer.o -MD -MP -MF 
rtems/.deps/no_timer_rel-no-timer.Tpo -c -o 
rtems/no_timer_rel-no-timer.o `test -f 'rtems/no-timer.c' || echo 
'/home/joel/rtems-4.11-work/build/rtems/c/src/optman/'`rtems/no-timer.c
error: error reading '4.10.99.0"'
In file included from <built-in>:109:
<command line>:5:24: error: missing terminating '"' character
#define PACKAGE_STRING "rtems-c-src
                        ^

This is from this -D option...

-DPACKAGE_STRING=\"rtems-c-src\ 4.10.99.0\"

Notice that there is an embedded space in the right hand side of the 
-DPACKAGE_STRING
which is causing the parsing of the command line to break.


The second problem is that native .h files are being picked up in a 
strictly cross
(x86-linux -> sparc-rtems) build.

In file included from ../../../sis/lib/include/sys/ioccom.h:91:
../../../sis/lib/include/rtems/bsd/sys/cdefs.h:63:9: warning: '__CONCAT' 
macro redefined [-pedantic]
#define __CONCAT(x,y)   __CONCAT1(x,y)
         ^
In file included from 
/home/joel/rtems-4.11-work/build/rtems/c/src/libchip/serial/ns16550.c:27:
In file included from /usr/include/stdlib.h:25:
In file included from /usr/include/features.h:361:
/usr/include/sys/cdefs.h:80:9: note: previous definition is here
#define __CONCAT(x,y)   x ## y


Finally RTEMS has some standard multilib libraries and headers and
some that are board (e.g. BSP) dependent.  We use a -B... option
to gcc.  So -BDIR adds DIR/include to the include path.  The analyser
seems to be not recognizing that option.  So it can't find the BSP
dependent .h files.

Of the ~100K SLOC of RTEMS, it analysed, we got 47 issues
(~75 with experimental turned on).  There is another ~600K of
code that it can't analyse because the test suite requires -B
to work.

I can provide any output, scripts, help, etc to reproduce and
track down the issues I encountered.  I would like to get to
the point where we ran the analyzer as part of our automated
build process on RTEMS.

Thanks.

--joel

> On Sep 19, 2010, at 1:19 PM, Joel Sherrill wrote:
>
>>   Hi,
>>
>> I configured RTEMS and then ran scan-build using a
>> modified version of the script we use to run Coverity
>> Scan.  It was:
>>
>> scan-build -o ${BASE}/output make>${BASE}/b.log 2>&1
>>
>> It looks like everything built OK but this was these
>> were the only messages from scan-build in the b.log file:
>>
>> scan-build: 'clang' executable not found in
>> '/usr/lib/clang-analyzer/scan-build/bin'.
>> scan-build: Using 'clang' from path: /usr/bin/clang
>> ......
>> scan-build: Removing directory
>> '/home/joel/rtems-4.11-work/build/gcc-testing/rtems/clang-analyzer/b-clang-sparc-rtems4.11/output/2010-09-19-1'
>> because it contains no reports.
>>
>> Does this mean this part of the RTEMS source was clean
>> on the first run?
>>
>> FWIW this is the subset we run Coverity Scan on and it has
>> ~95 issues with Coverity Scan.
>>
>> --joel
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com         On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985