Re: [PATCH 00/22] RFC: integrated 3rd-party static analysis support

[Jeff Law <law at redhat dot com>]

On 08/04/2017 04:04 PM, David Malcolm wrote:
> This patch kit clearly isn't ready yet as-is (see e.g. the
> "known unknowns" below), but I'm posting it now in the hope of
> getting early feedback.
[ ... ]

> 
> 
> Statement of the problem
> ========================
> 
> Static analysis is IMHO done too late, if at all: static analysis tools are run
> as an optional extra, "on the side", rather than in developers' normal
> workflow, with some kind of "override the compiler and do extra work" hook,
> which may preclude running more than one analyzer at once.  Analysis results
> are reviewed (if at all) in some kind of on-the-side tool, rather than when the
> code is being edited, or patches being prepared.
I'm sure you know my opinions on this stuff.  But for the benefit of the
rest of our readers, I agree, 100% totally on all of this.

For checkers to really be effective, they have to be part of the
standard workflow that we use every day.  Anything else is ultimately a
losing battle.  That's in large part why I continue to support improving
GCC's ability to emit high quality useful warnings about likely
programming errors.

So this raises one very high level question.  By providing this
capability do we undermine further development of GCC's down analysis
capabilities or does it merely allow that development to move to its
most natural place (gcc, llvm/clang, smatch, cppcheck, whatever)
allowing each tool to focus on what it does best?


> 
> It would also be good to tag binaries with information on what analyzers
> were run, what options they were invoked with, etc.
> Potentially have "dump_file" information from optimization passes stored
> in the metadata also.   Have a tool to query all of this.
So as you know this is a real area of interest for Red Hat.  Nick has
been playing in this space with his binary annotation project.  How are
these likely to interact with each other?

[ ... ]

> 
> 
> Known unknowns
> ==============
> 
> How does one suppress a specific false-positive site?
> Do we need a pragma for it?  (though pragmas ought to already affect some of
> the underlying checkers...)
I'm always conflicted on this kind of suppression/marking.  You can
easily end up with a boatload of unmaintainable markers.  But without
them you've got a firehose of useless information.  Sigh.


> 
> 
> Dependencies
> ============
> 
> The "checkers" subdirectory uses Python 2 or 3, and has a few Python
> dependencies, including "firehose" and "gccinvocation".
I'm not sure if there's general buy-in on firehose.  Not sure about
gccinvocation.  So these may need revisiting.

But we certainly need a way to suck in and present information to the
developers.  I'd prefer to re-use existing concepts and code, so JSON
may be the way to go for the interchange format.




JEff