From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32107 invoked by alias); 30 Sep 2014 17:26:44 -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 32094 invoked by uid 89); 30 Sep 2014 17:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 17:26:41 +0000 Received: by mail-ob0-f175.google.com with SMTP id m8so15551359obr.34 for ; Tue, 30 Sep 2014 10:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gMLYN5Z/Vux16s1+tL8hdeUo4RlhVQv/FWqc5qsLOV0=; b=UA2qd+IsTfFLVgC0S+QdcEHovKQe3JqFtdhjfT2x190uXpu7k8KGhQEZ8ukg7Pwt9o EETwClflurXORjsSOSLBizlkShFpiqixYMpPDcEXNFaBNqgnVzuT3k0KxyLB/HhLdhR6 Iv3nwgGejZGU/Ct/XMriK1UAVRvcQdIhI0SQqRMTw5E75/rGT2YhCFyCx4o3vQ2N4POB 3RPPtnbPxJqD4SRAM+n5gMfEWahT0yJI9qAsI7WfTVNiiURjYNJNtSoaDBnHvtWrD+4P 45xoICI3ohHl1qNhNwbdLAUMbGz8nYlO3MRFseAO+9GnQiWKay9d4Ftl96niFXiuwHm3 ujQQ== X-Gm-Message-State: ALoCoQlo9C4UNbdwQ/dqOW4AtRFi+vELME1ryqwrcdcNIf9QVbpzwkOtLVaeBEODP4rRwVqdX3er MIME-Version: 1.0 X-Received: by 10.60.51.71 with SMTP id i7mr2023519oeo.41.1412097999579; Tue, 30 Sep 2014 10:26:39 -0700 (PDT) Received: by 10.182.143.71 with HTTP; Tue, 30 Sep 2014 10:26:39 -0700 (PDT) In-Reply-To: <542A56C0.2030506@samsung.com> References: <54095E23.6050900@samsung.com> <5416B3A2.4050200@samsung.com> <54299507.7090800@samsung.com> <20140929174357.GH17454@tucnak.redhat.com> <20140929231720.GI17454@tucnak.redhat.com> <20140930054027.GJ17454@tucnak.redhat.com> <542A56C0.2030506@samsung.com> Date: Tue, 30 Sep 2014 17:26:00 -0000 Message-ID: Subject: Re: [PATCHv3][PING] Enable -fsanitize-recover for KASan From: Alexey Samsonov To: Yury Gribov Cc: Jakub Jelinek , Konstantin Serebryany , GCC Patches , Dmitry Vyukov , Andrey Ryabinin , Konstantin Khlebnikov Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-09/txt/msg02679.txt.bz2 On Tue, Sep 30, 2014 at 12:07 AM, Yury Gribov wrote: > On 09/30/2014 09:40 AM, Jakub Jelinek wrote: >> >> On Mon, Sep 29, 2014 at 05:24:02PM -0700, Konstantin Serebryany wrote: >>>> >>>> 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) >> >> >> The normal (non-recovery) callbacks are __attribute__((noreturn)) for >> performance reasons, and you do need different callbacks and different >> generated code if you want to recover (after the callback you need jump >> back to a basic block after the conditional jump). >> So, in that case you would need -fsanitize-recover=address. >> >>>> 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. >> >> >> That is fairly common case. > > > I think we can summarize: > * the current option -fsanitize-recover is misleading; it's really > -fubsan-recover > * we need a way to selectively enable/disable recovery for different > sanitizers > > The most promininet solution seems to be > * allow -fsanitize-recover=tgt1,tgt2 syntax > * -fsanitize-recover wo options would still mean UBSan recovery > > The question is what to do with -fno-sanitize-recover then. We can make -f(no-)?sanitize-recover= flags accept the same values as -f(no-)?sanitize= flags. In this case, "-fsanitize-recover" will be a deprecated alias of "-fsanitize-recover=undefined", and "-fno-sanitize-recover" will be a deprecated alias of "-fno-sanitize-recover=undefined". If a user provides "-fsanitize-recover=address", we can instruct the instrumentation pass to use recoverable instrumentation. > > -Y > -- Alexey Samsonov, Mountain View, CA