From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5714 invoked by alias); 24 Oct 2014 09:56:02 -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 5627 invoked by uid 89); 24 Oct 2014 09:56:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Fri, 24 Oct 2014 09:56:01 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9O9txA8011542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 05:55:59 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9O9tvF1009704 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Oct 2014 05:55:59 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9O9tuRi030492; Fri, 24 Oct 2014 11:55:56 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9O9ttXg030491; Fri, 24 Oct 2014 11:55:55 +0200 Date: Fri, 24 Oct 2014 09:59:00 -0000 From: Jakub Jelinek To: Dmitry Vyukov Cc: Yury Gribov , Andrey Ryabinin , GCC Patches , Konstantin Serebryany , Konstantin Khlebnikov Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan Message-ID: <20141024095555.GX10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5448CF90.2040001@samsung.com> <20141023095532.GD10376@tucnak.redhat.com> <5448D3EB.9030402@samsung.com> <20141023101649.GF10376@tucnak.redhat.com> <5448D986.5020300@samsung.com> <20141023103802.GG10376@tucnak.redhat.com> <5448E223.3020804@samsung.com> <544A0D92.5040002@samsung.com> <20141024095058.GW10376@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141024095058.GW10376@tucnak.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02511.txt.bz2 On Fri, Oct 24, 2014 at 11:50:58AM +0200, Jakub Jelinek wrote: > On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote: > > I am somewhat lost in this thread and probably missing something. > > But why do we need __asan_load (which is not noabort) at all? Outline > > instrumentation is non a default mode for both user-space asan and > > kasan (at least in the envisioned future). I would expect that these > > non-typical cases that use outline instrumentation can also bear the > > overhead of non-noreturn functions. Can we use just one version of > > __asan_load and let runtime decide on abort? > > __asan_load actually must never be noreturn, because in the common > case where the load is valid it of course returns. The point of __asan_load*_noabort (vs. __asan_load*) and __asan_report*_noabort (vs. __asan_report*) is to allow the choice what is fatal and what is not fatal to be done at compile time, per compilation unit. For __asan_report* that is a must, as __asan_report* without noabort is noreturn, for __asan_load* which is not noreturn the implementation can of course choose not to make something fatal when it wishes. Without -fsanitize-recover={address,kernel-address} support, the choice could be done only per program or kernel globally, without a way for programmer to differentiate. Jakub