GCC 11 and Static Analysis
Matthew J Fletcher
amimjf at gmail.com
Fri Jan 29 16:11:43 UTC 2021
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.
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.
>>> > <
>>> > 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.
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> 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:
>>> users mailing list
>>> users at rtems.org
>> users mailing list
>> users at rtems.org
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users