Re: GSoC: Working on the static analyzer

[David Malcolm <dmalcolm@redhat.com>]

On Fri, 2022-01-14 at 22:15 +0530, Mir Immad wrote:
> HI David,
> I've been tinkering with the static analyzer for the last few days. I
> find
> the project of adding SARIF output to the analyzer intresting. I'm
> writing
> this to let you know that I'm trying to learn the codebase.
> Thank you.

Excellent.

BTW, I think adding SARIF output would involve working more with GCC's
diagnostics subsystem than with the static analyzer, since (in theory)
all of the static analyzer's output is passing through the diagnostics
subsystem - though the static analyzer is probably the only GCC
component generating diagnostic paths.

I'm happy to mentor such a project as I maintain both subsystems and
SARIF output would benefit both - but it would be rather tangential to
the analyzer - so if you had specifically wanted to be working on the
guts of the analyzer itself, you may want to pick a different
subproject.

The SARIF standard is rather long and complicated, and we would want to
be compatible with clang's implementation.

It would be very cool if gcc could also accept SARIF files as an
*input* format, and emit them as diagnostics; that might help with
debugging SARIF output.   (I have a old patch for adding JSON parsing 
support to GCC that could be used as a starting point for this).

Hope the above makes sense
Dave

> 
> On Tue, Jan 11, 2022, 7:09 PM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote:
> > > Hi everyone,
> > 
> > Hi, and welcome.
> > 
> > > I intend to work on the static analyzer. Are these documents
> > > enough to
> > > get
> > > started: https://gcc.gnu.org/onlinedocs/gccint and
> > > 
> > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals
> > 
> > Yes.
> > 
> > There are also some high-level notes here:
> >   https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
> > 
> > Also, given that the analyzer is part of GCC, the more general
> > introductions to hacking on GCC will be useful.
> > 
> > I recommend creating a trivial C source file with a bug in it (e.g.
> > a
> > 3-line function with a use-after-free), and stepping through the
> > analyzer to get a sense of how it works.
> > 
> > Hope this is helpful; don't hesitate to ask questions.
> > Dave
> > 
> >