<div dir="ltr">Hi Matthew,<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021 at 9:11 AM Matthew J Fletcher <<a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Gedare,<div><br></div><div>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.</div><div><br></div><div>RTEMS is probably pretty clean compared to application codebases !</div><div><br></div><div>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.</div><div><br></div><div>regards, Matthew.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Jan 2021 at 15:29, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021 at 6:15 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 6:49 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Matthew,<br>
<br>
On 29/01/2021 10:14, Matthew J Fletcher wrote:<br>
> Hi,<br>
><br>
> Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion <br>
> of GCC 11 on the dev mailing list.<br>
you can already try out the GCC 11 based tools with the experimental <br>
RTEMS 7 tool chain available in the RSB.<br>
><br>
> I wonder if we (RTEMS users) could take advantage of the new static <br>
> analysis options in GCC 11.<br>
><br>
> <a href="https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/" rel="noreferrer noreferrer" target="_blank">https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/</a> <br>
> <<a href="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" rel="noreferrer noreferrer" target="_blank">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</a>> <br>
><br>
><br>
><br>
> Would seem very useful for embedded projects where runtime analysis is <br>
> difficult.<br>
Yes, you can give it a try. I never used it myself. The Coverity scan <br>
alone keeps me busy.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">In fairness, issues in common code gets fixed. Issues in random device drivers can tend to linger.</div><div dir="auto"><br></div><div dir="auto">Please experiment and report.</div></div></blockquote><div>Hi Matt,</div><div><br></div><div>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.</div><div><br></div><div>Gedare</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" rel="noreferrer" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br></div>
</blockquote></div>