GCC 11 and Static Analysis

Fri Jan 29 16:35:51 UTC 2021

Hi Matthew,

Sounds good. I will try to report if we make any progress on my end. We
intend to apply it to some additional code (EPICS) so that might give some
insights into the process that users might need for their applications.

On Fri, Jan 29, 2021 at 9:11 AM Matthew J Fletcher <amimjf at gmail.com> wrote:

> Hi Gedare,
>
> I suspect that the Coverty analysis of RTEMS is more mature than the
> GCC11 -fanalyzer at this stage, i was actually thinking of the
> possibilities that an integrated GCC option adds to RTEMS based, but closed
> source applications (such as ours), where other static options
> like Coverty and commercial options require a large investment of time.
> Runtime tools like Valgrind and their  commercial equivalents again need
> even higher time investments.
>
> RTEMS is probably pretty clean compared to application codebases !
>
> I think we will try an experimental move to RTEMS trunk for our
> application, set -fanalyzer and see what happens, but it's going to be a
> couple of months away at least.
>
> regards, Matthew.
>
>
>
> On Fri, 29 Jan 2021 at 15:29, Gedare Bloom <gedare at rtems.org> wrote:
>
>>
>>
>> On Fri, Jan 29, 2021 at 6:15 AM Joel Sherrill <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Fri, Jan 29, 2021, 6:49 AM Sebastian Huber <
>>> sebastian.huber at embedded-brains.de> wrote:
>>>
>>>> Hello Matthew,
>>>>
>>>> On 29/01/2021 10:14, Matthew J Fletcher wrote:
>>>> > Hi,
>>>> >
>>>> > Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion
>>>> > of GCC 11 on the dev mailing list.
>>>> you can already try out the GCC 11 based tools with the experimental
>>>> RTEMS 7 tool chain available in the RSB.
>>>> >
>>>> > I wonder if we (RTEMS users) could take advantage of the new static
>>>> > analysis options in GCC 11.
>>>> >
>>>> >
>>>> https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
>>>> > <
>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.redhat.com%2Fblog%2F2021%2F01%2F28%2Fstatic-analysis-updates-in-gcc-11%2F&data=04%7C01%7Cmatthew.fletcher%40se.com%7Cb41c34faa0154d5137e908d8c42830b3%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637475024180771568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SmQ4xfLBvYSeQUx0xd0jKC2z%2F89gRLH6IrHg17EJmUI%3D&reserved=0>
>>>>
>>>> >
>>>> >
>>>> >
>>>> > Would seem very useful for embedded projects where runtime analysis
>>>> is
>>>> > difficult.
>>>> Yes, you can give it a try. I never used it myself. The Coverity scan
>>>> alone keeps me busy.
>>>>
>>>
>>> Agreed. I had privately chatted with Gedare about this. He and some
>>> students had planned to or have looked at llvm's analyzer but this should
>>> be an easy step.
>>>
>>> The question on all these types analysis tools is how to manage the
>>> output. As a project, we do Coverity runs on leon3 for consistency. BSP
>>> doesn't matter for you if you want to pick at issues. But if it has
>>> warnings now, this will only increase the number.
>>>
>>> And it would be nice to think in terms of having automated reports
>>> available for the community and a scoreboard of some sort to track progress.
>>>
>>> But honestly, I've been reporting on warnings and analysis issues for
>>> years. Sometimes filing tickets. Sometimes fixing. It is an endless quest
>>> and hard to get broad help.
>>>
>>> In fairness, issues in common code gets fixed. Issues in random device
>>> drivers can tend to linger.
>>>
>>> Please experiment and report.
>>>
>> Hi Matt,
>>
>> Yes, if you're interested, we can talk more about looking into the GCC
>> static analyzer jointly. I will get around to it when I get around to it :)
>> Probably in April or May. I did get a student to product results from
>> clang-analyzer also, but haven't turned that into production-grade yet.
>> The big issue is triage and integration with workflows, and that is
>> something that requires work and thought from both the contributors and the
>> project maintainers.
>>
>> Gedare
>>
>>
>>>
>>> --joel
>>>
>>>
>>>
>>>> --
>>>> embedded brains GmbH
>>>> Herr Sebastian HUBER
>>>> Dornierstr. 4
>>>> 82178 Puchheim
>>>> Germany
>>>> email: sebastian.huber at embedded-brains.de
>>>> phone: +49-89-18 94 741 - 16
>>>> fax:   +49-89-18 94 741 - 08
>>>>
>>>> Registergericht: Amtsgericht München
>>>> Registernummer: HRB 157899
>>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>>> Unsere Datenschutzerklärung finden Sie hier:
>>>> https://embedded-brains.de/datenschutzerklaerung/
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210129/b0d85fa1/attachment-0001.html>