Re: Static analysis updates in GCC 11

[Martin Sebor <msebor@gmail.com>]

On 1/28/21 2:27 PM, David Malcolm via Gcc wrote:
> 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.
>>
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88391>
> 
> 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).

Florian suggested a similar approach (tags) as an enhancement to
the malloc attribute extension we've just added, to avoid having
to exhaustively associate every allocator with every deallocator.

Martin

> 
> 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
>