From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2591 invoked by alias); 18 Nov 2014 07:53:28 -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 2579 invoked by uid 89); 18 Nov 2014 07:53:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 18 Nov 2014 07:53:26 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAI7rORs007561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 18 Nov 2014 02:53:24 -0500 Received: from tucnak.zalov.cz (ovpn-116-73.ams2.redhat.com [10.36.116.73]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAI7rMe3030588 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Nov 2014 02:53:23 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id sAI7rLVV010949; Tue, 18 Nov 2014 08:53:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id sAI7rIYo010948; Tue, 18 Nov 2014 08:53:18 +0100 Date: Tue, 18 Nov 2014 08:34:00 -0000 From: Jakub Jelinek To: Alexey Samsonov Cc: Yury Gribov , Marek Polacek , GCC Patches , Dmitry Vyukov , Konstantin Serebryany Subject: Re: [PATCH] -fsanitize-recover=list Message-ID: <20141118075317.GF1745@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <542A56C0.2030506@samsung.com> <20140930173340.GI1986@tucnak.redhat.com> <20140930173913.GJ1986@tucnak.redhat.com> <543BADAB.4090000@samsung.com> <20141017161334.GF10376@tucnak.redhat.com> <20141118064740.GE1745@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.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg02209.txt.bz2 On Mon, Nov 17, 2014 at 11:39:47PM -0800, Alexey Samsonov wrote: > > That is not what I think we've agreed on and what is implemented in GCC. > > -fsanitize-recover only enables recovery of the undefined plus > > undefined-like sanitizers, in particular it doesn't enable recover from > > kernel-address, because -fsanitize-recover should be a deprecated option > > and kernel-address never used it before. > > Hm, indeed, I messed it up. In the older thread we agree that plain > -f(no-)sanitize-recover > should be a deprecated synonym for the current meaning of these flags, > which only specify recoverability for UBSan-related checks :-/ > > Has GCC already shipped with existing implementation? I'm just curious > if it's convenient to have flags that would enable/disable recovery for all > sanitizers (analogous to -Werror flags which exist in a standalone form, but > may accept specific warnings, so that one can write > "$(CC) foo.cc -Wno-error -Werror=sign-compare" Well, no sanitizer is on by default, so you can just use the same list for -fno-sanitize-recover= or -fsanitize-recover= as for -fsanitize= if you want. > > So, in GCC -fsanitize-recover stands for > > -fsanitize-recover=undefined,float-divide-by-zero,float-cast-overflow > > and -fno-sanitize-recover stands for > > -fno-sanitize-recover=undefined,float-divide-by-zero,float-cast-overflow > > > > > * -fsanitize-recover=: Enable recovery for all selected checks > > > or group of checks. It is forbidden to list unrecoverable sanitizers > > > here (e.g., "-fsanitize-recover=address" will produce an error). > > > > We only error on > > -fsanitize-recover=address > > -fsanitize-recover=thread > > -fsanitize-recover=leak > > Right, it's a good idea to error on sanitizer kinds we don't have > recovery for. I will > add the errors for TSan/MSan/LSan etc. > > > but not say on > > -fsanitize-recover=unreachable > > which is part of undefined; unreachable isn't recoverable silently. > > Likewise -fsanitize-recover=return. Otherwise one couldn't use > > -fsanitize-recover=undefined which is useful. > > Can't this be fixed by checking the actual values of -fsanitize-recover= flag > before expanding the sanitizer groups (i.e. turning "undefined" into > "null,unreachable,return,....")? > > We should probably be able to distinguish between -fsanitize-recover=undefined, > and -fsanitize-recover=unreachable,. > In the first case we can enable recovery > for all parts of "undefined" that support it. In the second, we can > produce an error as user > explicitly tried to enable recovery for sanitizer that doesn't support it. But in that case you would need to diagnose it already when parsing the option, or add code that would remember what bits have been set from other option sets. In the former case, you'd diagnose even -fsanitize-recover=unreachable -fno-sanitize-recover=undefined even when in that case unreachable in the end is not recoverable. We don't error out for -fsanitize-recover=address -fno-sanitize-recover=address because in the end address is not recovered. Jakub