GCC Working On 3rd Party Static Analysis Support

[phoronix]

Phoronix: GCC Working On 3rd Party Static Analysis Support

Red Hat's David Malcom has posted a series of patches for implementing third-party static analysis support within the GNU Compiler Collection (GCC)...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-3rd-Party-Analysis

[timofonic]

What about license compatibility with these tools?

[discordian]

What about license compatibility with these tools?

Since they will be loaded with OS Functions and not linked in directly, its of no concern. Its already possible to add "proprietary optimization passes" AFAIK.

https://gcc.gnu.org/onlinedocs/gccint/Plugins-loading.html#Plugins-loading

[timofonic]

Since they will be loaded with OS Functions and not linked in directly, its of no concern. Its already possible to add "proprietary optimization passes" AFAIK.

https://gcc.gnu.org/onlinedocs/gccint/Plugins-loading.html#Plugins-loading

Are you sure? I see they are "plugins"...

Plugins are supported on platforms that support -ldl -rdynamic. They are loaded by the compiler using dlopen and invoked at pre-determined locations in the compilation process.

[Konstantin A.]

Excuse my ignorance, since i have just start learning C. What does that mean in simple words?
You won't have to use tools like Valgrind or splint? Or they merge the functionality of gdb into gcc?

[oiaohm]

Excuse my ignorance, since i have just start learning C. What does that mean in simple words?
You won't have to use tools like Valgrind or splint? Or they merge the functionality of gdb into gcc?

First understand difference between static analysis and dynamic analysis.

Valgrind is dynamic analysis meaning it performed on built applications. So this feature not related to dynamic analysis tools at all.

Splint is static analysis. So this is the right camp of tools.

This is a interface so that when you are building program you can tell gcc to go run a set of preferred static analysis tools in the build process even bail out if there are messages. Of course the static analysis tool with either have to be wrapped or talking in the interface gcc is expecting being the firehose json protocol.

This is not a gdb feature change.

Big thing is to reduce workflow issues. Where you build code with a modification only to have a error turn up latter that would have been avoid if you had remembered to run the static analysis tool. The big common issue with static analysis tools that you see all the time.

http://events.linuxfoundation.org/sites/events/files/slides/Static%20code%20checking.pdf

Like you are building the Linux kernel there is at least 6 different different static analysis tools you will be interested in running to find the most number of bugs. You missing running one you might submit a patch where the automatic bot pulled out out for carelessness.

So the problem here is workflow. 1) code 2) static analysis 3) build binary 4) dynamic analysis is existing work flow. With people stuffing up a lot on step 2 or completely missing doing it.

The change makes it 1) code 2) static analysis and build 3) dynamic analysis. Shorter work-flow less to stuff up.

Of course gcc build stage with warning messages has been doing a little bit to static analysis but compliers being generic cannot do like the Linux kernel sparse does checking Linux kernel particular things.

Like it could see the in Linux kernel checkpatch.pl script checks on by default. Yes it would mean a lot of work cleaning up existing code base issues. So programs that ship with there own static analysis tools could make it part of their default build process so reducing developer option to avoid the tool.

[discordian]

Are you sure? I see they are "plugins"...

Yes, but gcc is using the plugins, not the other way around. Arguably the interface is from gcc, but this is not under Gpl by choice (Afaik).

[hansg]

Yes, but gcc is using the plugins, not the other way around. Arguably the interface is from gcc, but this is not under Gpl by choice (Afaik).

It's linked, and that's the only thing referred to in the GPL. It doesn't say anything about who's calling what.

[discordian]

It's linked, and that's the only thing referred to in the GPL. It doesn't say anything about who's calling what.

dynamic linking a plugin is something different than depending on a part of a program. it doesnt matter who ist calling whom, it does matter who sits on top. With your logic, you couldn`t run GPL software on eg. Windows.
The key word is "derivate work", and unfortunately this isnt handled with a few sentences. Rule of the thumb is that talking over defined interfaces breaks the dependency, but since those typically come with headers and often glue-code this doesn`t suffice.
See the state of linux-drivers, which more or less depend on whether the kernel-module was written for Linux or ported to its API.

gcc`s plugin system has the explicit aim to allow propietary code.

[timofonic]

dynamic linking a plugin is something different than depending on a part of a program. it doesn't matter who is calling whom, it does matter who sits on top. With your logic, you couldn't run GPL software on eg. Windows.
The key word is "derivative work", and unfortunately this isn't handled with a few sentences. Rule of the thumb is that talking over defined interfaces breaks the dependency, but since those typically come with headers and often glue-code this doesn't suffice.
See the state of linux-drivers, which more or less depend on whether the kernel-module was written for Linux or ported to its API.

gcc's plugin system has the explicit aim to allow proprietary code.

The Linux kernel case really violates the GPL. I hope someday Nvidia, Imagination Technologies, Tuxera and VMWare gets sued someday (among others).

Are you sure of that? Are there explicit declarations by the GCC developers and project leader(s)? What does RMS think about this?