From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 8EEEB39DC4E7 for ; Thu, 28 Jan 2021 21:27:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8EEEB39DC4E7 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-QDCns3DaP5Cbp_zY3MSVJg-1; Thu, 28 Jan 2021 16:27:50 -0500 X-MC-Unique: QDCns3DaP5Cbp_zY3MSVJg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C2E34802B40; Thu, 28 Jan 2021 21:27:48 +0000 (UTC) Received: from t14s.localdomain (ovpn-112-59.phx2.redhat.com [10.3.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5972F72160; Thu, 28 Jan 2021 21:27:48 +0000 (UTC) Message-ID: Subject: Re: Static analysis updates in GCC 11 From: David Malcolm To: David Brown , gcc@gcc.gnu.org Date: Thu, 28 Jan 2021 16:27:47 -0500 In-Reply-To: <1133c1d0-bc2d-d088-be0e-168865f2ed07@hesbynett.no> References: <1133c1d0-bc2d-d088-be0e-168865f2ed07@hesbynett.no> User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 21:27:54 -0000 On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote: > On 28/01/2021 21:23, David Malcolm via Gcc wrote: > > I wrote a blog post covering what I've been working on in the > > analyzer > > in this release: > >  https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ > > > > As a gcc user, I am always glad to hear of more static analysis and > static warning work.  My own work is mostly on small embedded > systems, > where "malloc" and friends are severely frowned upon in any case and > there is no file system, so most of the gcc 10 -fanalyzer warnings > are > of no direct use to me.  (I still think they are great ideas - even > if > /I/ don't write much PC code, everyone benefits if there are fewer > bugs > in programs.)  I will get more use for the new warnings you've added > for > gcc 11. > > > I wrote a feature request for gcc a while back, involving adding tag > attributes to functions in order to ensure that certain classes of > functions are only used from specific allowed functions.  The feature > request attracted only a little interest at the time.  But I suspect > it > could work far better along with the kind of analysis you are doing > with > -fanalyzer than with the normal syntactical analyser in gcc. > > Interesting. The attribute ideas seem designed to work with the callgraph: partitioning the callgraph into families of functions for which certain kinds of inter-partition edges are disallowed. Can a function change its tag internally, or is it assumed that a function has a single tag throughout its whole body? I see that you have a case in example 3 where a compound statement is marked with an attribute (which may be an extension of our syntax). One thing I forgot to mention in the blog post is that the analyzer now supports plugins; there's an example of a mutex-checking plugin here: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825 which is similar to your examples 1 and 3. Your example 2 is also reminiscent of the async-signal-unsafe checking that the analyzer has (where it detects code paths that are called within a signal handler and complains about bad calls within them). Many of the existing checks in the analyzer are modelled as state machines (either global state for things like "are we in a signal handler", or per-value state for things like "has this pointer been freed"), and your examples could be modelled that way too (e.g. "what sections are in RAM" could be a global state) - so maybe it could all be done as analyzer plugins, in lieu of implementing the RFE you posted. Hope this is constructive Dave