From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96121 invoked by alias); 2 Nov 2016 09:52:11 -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 96038 invoked by uid 89); 2 Nov 2016 09:52:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1806 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; Wed, 02 Nov 2016 09:52:08 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D27675455D; Wed, 2 Nov 2016 09:52:07 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA29q6D4011768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Nov 2016 05:52:07 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uA29q45i018541; Wed, 2 Nov 2016 10:52:04 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uA29q3sH018540; Wed, 2 Nov 2016 10:52:03 +0100 Date: Wed, 02 Nov 2016 09:52:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Martin =?utf-8?B?TGnFoWth?= , GCC Patches Subject: Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2) Message-ID: <20161102095202.GL3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160818133609.GN14857@tucnak.redhat.com> <98f408c5-7e1e-6fd8-e589-34f8de2f4455@suse.cz> <20161007111347.GF7282@tucnak.redhat.com> <20161021142617.GG7282@tucnak.redhat.com> <3a109250-0440-7438-8e1f-7e5c6d8b6580@suse.cz> <20161027172358.GN3541@tucnak.redhat.com> <606cd948-6cba-02a4-f114-35900ab53203@suse.cz> <20161101151219.GT3541@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00134.txt.bz2 On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote: > > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property > > set during the asan pass and kept on until end of compilation of that > > function. That means even if a var only addressable because of ASAN_MARK is > > discovered after this pass we'd still be able to rewrite it into SSA. > > Note that being TREE_ADDRESSABLE also has effects on alias analysis > (didn't follow the patches to see whether you handle ASAN_MARK specially > in points-to analysis and/or alias analysis). > > Generally in update-address-taken you can handle ASAN_MARK similar to > MEM_REF (and drop it in the rewrite phase?). That is the intent, but we can't do that before the asan pass, because otherwise as Martin explained we don't diagnose at runtime bugs where a variable is used outside of its scope only through a MEM_REF. So we need to wait for asan pass to actually add a real builtin call that takes the address in that case. Except now I really don't see how that can work for the case where the var is used only properly when it is in the scope, because the asan pass will still see those being addressable. Unless I'm missing something we either need to perform further analysis during the addressable subpass - this variable could be made non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA form there be any SSA uses of the poisoning ASAN_MARK? If yes, keep it addressable, otherwise rewrite into SSA. Or, just rewrite it into SSA always, but turn the poisoning ASAN_MARK into some new internal ECF_CONST call var_5 = ASAN_POISON (); and if we have any uses of those, rewrite it back into addressable immediately or later or something. Jakub