Issue #2 with clang-analyzer on RTEMS

Hi,

Issue #2 I encountered...

The second problem is that native .h files are being picked up in a
strictly cross (x86-linux -> sparc-rtems) build. I used the following
command to run the analysis.

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

where RTEMS_TARGET was sparc-rtems4.11

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: <====************* NATIVE
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

Thanks.

--joel sherrill
RTEMS

Hello, Joel

The second problem is that native .h files are being picked up in a
strictly cross (x86-linux -> sparc-rtems) build. I used the following
command to run the analysis.

This is pretty much expected: cross-compilation features in clang are
currently pretty poor.
Most probably you will need to create your own target definition
inside clang and tune the
driver to look for correct include paths.

Hmm... we have 13 target cpus and they all follow
the same patterns which are "GNU-itically" correct.
We install into a ${prefix} and the includes are
in the right ${prefix}/${target}/include EXCEPT
for the board dependent ones which we tell gcc about
using the -B option.

Is there a simple way to tell it to ignore native
includes? Or is there a simple way to have it learn
all of our targets without having to add 13 compiler
descriptions?

--joel

Hello

Is there a simple way to tell it to ignore native
includes?

Probably some combination of -isystem and other options might help...
But this is surely a workaround.

Or is there a simple way to have it learn
all of our targets without having to add 13 compiler
descriptions?

How do you see this? E.g. how the compiler can learn about stuff like
sizeof(long) for your target?

Hello

Is there a simple way to tell it to ignore native
includes?

Probably some combination of -isystem and other options might help...
But this is surely a workaround.

Wouldn't that just add directories but not remove them from
the list clang-analyzer is looking at?

Or are you suggesting we change our build arguments
to something clang-analyzer understands?

Or is there a simple way to have it learn
all of our targets without having to add 13 compiler
descriptions?

How do you see this? E.g. how the compiler can learn about stuff like
sizeof(long) for your target?

Can't it use the .h files gcc already provided? We are one of
the Coverity Scan program members and I don't have to teach it
this type of information. I point it at a compiler and it analyses
the source.

I am only using the analyzer. Not trying to actually compile to
machine code.

How do you see this? E.g. how the compiler can learn about stuff like
sizeof(long) for your target?

Can't it use the .h files gcc already provided?

Stuff like builtin type sizes does not come from any headers. If you
do stuff like
void* p;
int a = (int)p

then, depending on size of int and void* on given platform, there
might be truncation or not.
Think about the sign of char, etc.

We are one of the Coverity Scan program members and I don't have to teach it
this type of information. I point it at a compiler and it analyses
the source.

I have no idea what Coverity is doing "inside" and how they deal with
all that stuff.

Hello

Is there a simple way to tell it to ignore native
includes?

Probably some combination of -isystem and other options might help...
But this is surely a workaround.

Wouldn't that just add directories but not remove them from
the list clang-analyzer is looking at?

The usual way to do this with gcc is something like:
powerpc-softfloat-linux-gcc -sysroot /my/cross/tree/is/here -c foo.c

But, you also end up having a gcc per target architecture, built with the options you need.

For clang, how about extending gcc's spec file notion to include all the necessary information? That way you don't have to rebuild the compiler every time you add a CPU to your build system, provided it was already supported by clang. It would be nice if clang --triple would find a spec file for that triple and pick up all the rest of the necessary options from there; then the above compiler invocation becomes:
clang --triple=powerpc-softfloat-linux -sysroot /my/cross/tree/is/here -c foo.c

Obviously that requires supporting -sysroot, and I'd strongly suggest the spec file should be found INSIDE the sysroot; then you can have your build system put it there, which means you have it under version control, rather than having to add yet more arguments as you do with gcc.

Or are you suggesting we change our build arguments
to something clang-analyzer understands?

Or is there a simple way to have it learn
all of our targets without having to add 13 compiler
descriptions?

How do you see this? E.g. how the compiler can learn about stuff like
sizeof(long) for your target?

Can't it use the .h files gcc already provided? We are one of
the Coverity Scan program members and I don't have to teach it
this type of information. I point it at a compiler and it analyses
the source.

I am only using the analyzer. Not trying to actually compile to
machine code.

You can teach scan-build how to invoke clang for a particular target... it's in perl, which is pretty horrible, but that's where to make the modifications. -isysroot is your friend.

Andrew

For clang, how about extending gcc's spec file notion to include all the necessary information?

Don't do that (tm) :slight_smile:

gcc specs stuff is an good example how the stuff should not look like.
You might find http://clang.llvm.org/UniversalDriver.html somehow
useful. Noone started to do anything significant in this direction
besides some early experiments.

I wasn't thinking of copying the syntax... that's hideous.

But the concept of a compiler config file that encapsulates the directory layout (relative to a small number of places that can be specified with something like -sysroot) and all the details of linker etc. invocations, that's a good idea.

Andrew

Just to be clear, the main role of scan-build and ccc-analyzer is to interpose on the build and run the analyzer on each file by executing 'clang'. Information about specific targets, including processing command line options, should be put in clang, not scan-build or ccc-analyzer. Beyond being the only solution that will likely work in practice, it pays dividends in the future when bringing up the Clang compiler on the same platform.