From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2202 invoked by alias); 30 Sep 2014 00:24:27 -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 2192 invoked by uid 89); 30 Sep 2014 00:24:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f175.google.com Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 00:24:26 +0000 Received: by mail-vc0-f175.google.com with SMTP id hy4so5259774vcb.20 for ; Mon, 29 Sep 2014 17:24:23 -0700 (PDT) X-Received: by 10.52.238.227 with SMTP id vn3mr3286007vdc.47.1412036663869; Mon, 29 Sep 2014 17:24:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.105.232 with HTTP; Mon, 29 Sep 2014 17:24:02 -0700 (PDT) In-Reply-To: References: <54095E23.6050900@samsung.com> <5416B3A2.4050200@samsung.com> <54299507.7090800@samsung.com> <20140929174357.GH17454@tucnak.redhat.com> <20140929231720.GI17454@tucnak.redhat.com> From: Konstantin Serebryany Date: Tue, 30 Sep 2014 00:24:00 -0000 Message-ID: Subject: Re: [PATCHv3][PING] Enable -fsanitize-recover for KASan To: Alexey Samsonov Cc: Jakub Jelinek , Yury Gribov , GCC Patches , Dmitry Vyukov , Andrey Ryabinin , Konstantin Khlebnikov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg02596.txt.bz2 On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote: > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote: >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote: >>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we >>> never use "?san" >>> in flag names, preferring -fsanitize-whatever. What's the rationale behind >>> splitting >>> -fsanitize-recover in two flags (ASan- and UBSan- specific)? >>> Is there no way to keep a single -f(no-)sanitize-recover for that purpose? >>> Now it works >>> only for UBSan checks, but we may extend it to another sanitizers as well. >> >> The problem is that if we start using it for ASan, it needs to have a >> different default, because ASan wants to abort by default, while UBSan >> recover by default. -fsanitize=kernel-address w (KASan) wants to recover >> by default. So, the option is either to never support recover for >> -fsanitize=address, for ubsan keep -fsanitize-recover (by default) as is >> and for kasan use that same switch, or have separate flags. >> >> Jakub > > I don't think we ever going to support recovery for regular ASan > (Kostya, correct me if I'm wrong). I hope so too. Another point is that with asan-instrumentation-with-call-threshold=0 (instrumentation with callbacks) we can and probably will allow to recover from errors (glibc demands that), but that does not require any compile-time flag. > I see no problem in enabling -fsanitize-recover by default for > -fsanitize=undefined and This becomes more interesting when we use asan and ubsan together. Which default setting is stronger? :) > -fsanitize=kernel-address. We can, potentially, extend > -fsanitize-recover flag to take the same values as -fsanitize= one, > so that one can specify which sanitizers are recoverable, and which > are not, but I'd try to make this a last resort - this is too complex. > > -- > Alexey Samsonov, Mountain View, CA