From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123652 invoked by alias); 9 Sep 2019 10:49:25 -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 123644 invoked by uid 89); 9 Sep 2019 10:49:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:c843cab, H*i:sk:c843cab, google, HContent-Transfer-Encoding:8bit X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2019 10:49:23 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 669EAAFA8; Mon, 9 Sep 2019 10:49:21 +0000 (UTC) Subject: Re: [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan To: Matthew Malcomson , "gcc-patches@gcc.gnu.org" Cc: "dodji@redhat.com" , nd , "kcc@google.com" , "jakub@redhat.com" , "dvyukov@google.com" References: <156778058239.16148.17480879484406897649.scripted-patch-series@arm.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <32fb4525-2eda-ef6f-f4f3-3db87e259b40@suse.cz> Date: Mon, 09 Sep 2019 10:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00489.txt.bz2 On 9/9/19 12:29 PM, Matthew Malcomson wrote: > On 09/09/19 11:01, Martin Liška wrote: >> Hi. >> >> On 9/6/19 4:46 PM, Matthew Malcomson wrote: >>> Ensuring that the shadow stack is cleared on normal function exit will >>> be done by adding instrumentation to the function epilogue through the >>> compiler. >>> longjmp and setjmp are some abnormal methods of exiting the function >>> that can't be handled in the compiler since they can be called in >>> uninstrumented code to unwind past instrumented function frames. >> >> I'm curious why you are adding a new code that is not part of libsanitizer runtime? >> Does it mean the current LLVM implementation does not properly handle setjmp and >> longjmp? > > Honestly -- I'm not sure. > > I did a basic test that seemed to show clang not supporting setjmp & > longjmp and I made a bit of a foray into how one would approach the > problem, but I then left it in a partially done state to focus on other > things. I see. Then I would probably file an issue and ask the community: https://github.com/google/sanitizers/issues > > It also seems on first blush that C++ exceptions are not handled, but > again I haven't yet gone and asked anyone in the know. Likewise I would ask them for the C++ exceptions. Martin > > (it's on the list of things to do, but not yet at the top). > >> >> Note that rule of thumb is that we need to upstream all libsanitizer >> changes before we merge libsanitizer. We are doing that in order to not >> have a bug difference against upstream libsanitizer. > > That sounds good to me -- I will remember to go upstream when I look > into this. > >> >> Martin >> >