clang-analyze on RTEMS

[Joel Sherrill]

  On 09/20/2010 07:23 AM, Ralf Corsepius wrote:
> On 09/20/2010 01:35 PM, Joel Sherrill wrote:
>> On 09/19/2010 10:39 PM, Ralf Corsepius wrote:
>>> On 09/20/2010 03:21 AM, Joel Sherrill wrote:
>>>> Hi,
>>>>
>>>> I have run clang-analyze on RTEMS. Running
>>>> it on the same subset we run Coverity Scan
>>>> on produced no issues. I don't know if clang
>>>> will turn up anything but it is another
>>>> tool in the arsenal. So I tried to run it
>>>> on everything and got this:
>>>>
>>>> checking for style of include used by gmake... GNU
>>>> checking for sparc-rtems4.11-gcc...
>>>> /usr/lib/clang-analyzer/scan-build/ccc-analyzer
>>>> checking for sparc-rtems4.11-gcc... (cached)
>>>> /usr/lib/clang-analyzer/scan-build/ccc-analyzer
>>>> checking whether the C compiler works... no
>>>> configure: error: in
>>>> `/home/joel/rtems-4.11-work/build/gcc-testing/rtems/clang-analyzer/b-clang-sparc-rtems4.11/sparc-rtems4.11/c/sis':
>>>>
>>>>
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details.
>>>> gmake[2]: *** [sis] Error 1
>>>> gmake[2]: Leaving directory
>>>> `/home/joel/rtems-4.11-work/build/gcc-testing/rtems/clang-analyzer/b-clang-sparc-rtems4.11/sparc-rtems4.11/c'
>>>>
>>>>
>>>>
>>>> It is pretty easy to run .. just configure .. then
>>>>
>>>> scan-build -o output_dir make
>>>>
>>>> Any thoughts on why the autoconf test fails?
>>> Me never having used clang and you not providing sufficient informations
>>> to be able to help, only 2 general remarks:
>>>
>>> * General answer from the "top autoconf newbie answering templates'
>>> drawer":
>>>
>>> Do as autoconf tells you - "See 'config.log' for details"
>>>
>> OK. Should have posted that. My hunch from the output matches
>> what config.log (attached) shows. It tries to use ccc-analyzer as
>> the compiler.
> Seems so, ... and it seems to fail badly:
>
> configure:3368: checking whether the C compiler works
> configure:3390: /usr/lib/clang-analyzer/scan-build/ccc-analyzer
> -mcpu=cypress -O2 -g   conftest.c>&5
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> conftest.c:1: error: bad value (cypress) for -mtune= switch
> configure:3394: $? = 1
> configure:3432: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "rtems-c-src"
> | #define PACKAGE_TARNAME "rtems-c-src"
> | #define PACKAGE_VERSION "4.10.99.0"
> | #define PACKAGE_STRING "rtems-c-src 4.10.99.0"
> | #define PACKAGE_BUGREPORT "http://www.rtems.org/bugzilla"
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
>
> Wild guess: This clang seems to be a native-only tool.
>
> The error above likely originates from a native i386/x86_64-gcc:
>
> # touch tmp.c
>
> # gcc -mcpu=cypress -O2 -g   tmp.c
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> tmp.c:1: error: bad value (cypress) for -mtune= switch
>
> # /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -mcpu=cypress -O2 -g   tmp.c
> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.5.1/../../../../sparc-rtems4.11/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 0000000000010074
>
I suppose this needs to move to the clang list then. :(

I will cc you.  I am about to fly out for the week but will do it
from the hotel when I get there.
>> Attached is my script to drive this.
>>> * Knowing you are building on x86_64, your log message referring to
>>> /usr/lib/clang-ananlyser indicates your "clang"-package is likely
>>> misconfigured/incorrectly installed.
>>>
>>>
>> It is the RPM from Fedora 13 on my home laptop. I was killing
>> some time and tried it.
> So this is an i386 installation?
>
> Except if this laptop is old or is an Atom-powered netbook, this rarly
> makes sense.
vendor_id    : GenuineIntel
cpu family    : 6
model        : 14
model name    : Genuine Intel(R) CPU           T2500  @ 2.00GHz
stepping    : 8
cpu MHz        : 1000.000
cache size    : 2048 KB


> Ralf