Improve Coverity Scan Integration: GSOC project details

[Joel Sherrill]

On Mon, Mar 2, 2020 at 11:16 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> ----- Am 2. Mrz 2020 um 17:02 schrieb Gedare Bloom gedare at rtems.org:
>
> > On Sun, Mar 1, 2020 at 6:31 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >>
> >>
> >> On Sun, Mar 1, 2020, 1:02 PM suyash singh <suyashsingh234 at gmail.com>
> wrote:
> >>>
> >>> This is regarding the project I would like to work in
> >>>
> >>> Improve Coverity Scan Integration
> >>> https://devel.rtems.org/ticket/3710
> >>>
> >>> FIRST POINT-
> >>> I was thinking about implementing Coverity or clang analyzer as an
> offline
> >>> analyzer. Would it be a suitable idea to make a separate repo just for
> testing
> >>> purposes?
> >>> This "testing repository" will have the updated rtems code as well the
> analyzer
> >>> in it. If possible this repo will be updated automatically from the
> main repo.
> >>
> >>
> >> I would have to see how the clang analyser is run against the RTEMS
> source. My
> >> expectation would be that ultimately something would be added to
> rtems-tools to
> >> run the analysis process and generate reports.
> >>
> >> The reports could then be locally generated or run on an rtems.org
> server for
> >> publication.
> >>
> >> I don't see needing a private RTEMS repository. This should be an
> rtems-tools
> >> project and you would only have a personal copy of that for the
> purposes of
> >> getting reviews. Usually patches just get submitted and you don't need
> a public
> >> facing repo at all.
> >>
> >>
> >
> > I have someone attempting to replicate the recent instructions how to
> > use clang-analyzer. I will share results if we succeed.
> >
> > It is possible to run open-source analyzers (like clang, cppcheck) on
> > a repo. For a GSoC, it would be fine to work on an RTEMS/RTEMS-Tools
> > fork, with the intent to deliver upstream.
>
> For GSoC I would focus on the open tools.


+1 Coverity is good but behind a wall that will always limit who sees
anything.

Plus if we fix issues found by other tools, it is possible they are the
Coverity
issues.


> For clang-analyzer there is also the Thread Safety Analysis.
>
> https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
>
> It could be used for the SMP locks for example. There are also the LLVM
> sanitizers:
>
> https://github.com/google/sanitizers
>
> I expect that most bugs will be in RTEMS applications and the complex
> network and device driver frameworks, e.g. libbsd. Being able to use some
> of the sanitizers in RTEMS would be great. The question is if you need
> virtual memory for them.
>
> >
> > Unfortunately, you can't easily run Coverity offline or on your own
> > repository. To use the free version you need to run it through their
> > interface. At least, I don't know if you can download/run
> > coverity-scan free version. That is something you could take a look
> > at. Longer term, I don't think Coverity is the right tool for the
> > community because of the restrictions on the open version. However, we
> > should continue to improve how we use it. I'm becoming more convinced
> > that we need to identify suitable open-source static analysis tools
> > that help us to improve our products.
>
> A big problem with Coverity is that the documentation is not open.
>

I'm not even sure Scan has all the capabilities of the paid product. I get
the impression that it doesn't.

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200302/5d8c3ab2/attachment-0001.html>