From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72936 invoked by alias); 1 Sep 2017 17:46:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 72927 invoked by uid 89); 1 Sep 2017 17:46:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=battle, suppression, quality X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Sep 2017 17:46:44 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2613D806B8 for ; Fri, 1 Sep 2017 17:46:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2613D806B8 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5FE5D77DC1; Fri, 1 Sep 2017 17:46:42 +0000 (UTC) Subject: Re: [PATCH 00/22] RFC: integrated 3rd-party static analysis support To: David Malcolm , gcc-patches@gcc.gnu.org References: <1501884293-9047-1-git-send-email-dmalcolm@redhat.com> From: Jeff Law Message-ID: Date: Fri, 01 Sep 2017 17:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1501884293-9047-1-git-send-email-dmalcolm@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00078.txt.bz2 On 08/04/2017 04:04 PM, David Malcolm wrote: > This patch kit clearly isn't ready yet as-is (see e.g. the > "known unknowns" below), but I'm posting it now in the hope of > getting early feedback. [ ... ] > > > Statement of the problem > ======================== > > Static analysis is IMHO done too late, if at all: static analysis tools are run > as an optional extra, "on the side", rather than in developers' normal > workflow, with some kind of "override the compiler and do extra work" hook, > which may preclude running more than one analyzer at once. Analysis results > are reviewed (if at all) in some kind of on-the-side tool, rather than when the > code is being edited, or patches being prepared. I'm sure you know my opinions on this stuff. But for the benefit of the rest of our readers, I agree, 100% totally on all of this. For checkers to really be effective, they have to be part of the standard workflow that we use every day. Anything else is ultimately a losing battle. That's in large part why I continue to support improving GCC's ability to emit high quality useful warnings about likely programming errors. So this raises one very high level question. By providing this capability do we undermine further development of GCC's down analysis capabilities or does it merely allow that development to move to its most natural place (gcc, llvm/clang, smatch, cppcheck, whatever) allowing each tool to focus on what it does best? > > It would also be good to tag binaries with information on what analyzers > were run, what options they were invoked with, etc. > Potentially have "dump_file" information from optimization passes stored > in the metadata also. Have a tool to query all of this. So as you know this is a real area of interest for Red Hat. Nick has been playing in this space with his binary annotation project. How are these likely to interact with each other? [ ... ] > > > Known unknowns > ============== > > How does one suppress a specific false-positive site? > Do we need a pragma for it? (though pragmas ought to already affect some of > the underlying checkers...) I'm always conflicted on this kind of suppression/marking. You can easily end up with a boatload of unmaintainable markers. But without them you've got a firehose of useless information. Sigh. > > > Dependencies > ============ > > The "checkers" subdirectory uses Python 2 or 3, and has a few Python > dependencies, including "firehose" and "gccinvocation". I'm not sure if there's general buy-in on firehose. Not sure about gccinvocation. So these may need revisiting. But we certainly need a way to suck in and present information to the developers. I'd prefer to re-use existing concepts and code, so JSON may be the way to go for the interchange format. JEff