scan-build on RTEMS (try #1)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

scan-build on RTEMS (try #1)

Joel Sherrill
  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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build on RTEMS (try #1)

Ted Kremenek
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.

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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


--
Joel Sherrill, Ph.D.             Director of Research&  Development
[hidden email]         On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev