From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18559 invoked by alias); 20 Dec 2016 14:33:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18549 invoked by uid 89); 20 Dec 2016 14:33:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy==e5=b0=a7, Hx-languages-length:923, H*f:sk:fdfc0c0, H*i:sk:fdfc0c0?= X-HELO: mail-wj0-f194.google.com Received: from mail-wj0-f194.google.com (HELO mail-wj0-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Dec 2016 14:33:33 +0000 Received: by mail-wj0-f194.google.com with SMTP id he10so27973072wjc.2 for ; Tue, 20 Dec 2016 06:33:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=F8pvQuLp+g+YMyUHlPVxrm+FnqmTp3PuEvxuSSBf05k=; b=kZ2LUnpLmd55qVzCSVFwEzxTaqHXZv9M3JzBxbGuUjgq3nImCmLi6Nd6Y8z6BYcMWu g4X/VPoZY++EtgoiTsqlAiwXKXZAe05+749HYdaPxKhTwqSwQgA290ql0UNLcYyKVnnx z3YG/MCHDtuIV2eUM0mL5Jby0sqdAw9ZghwxQWfz8cHTKoaPt8Jlu35mVi3dgtPgVqsD GSHOKb3HmCRbhsQ3uGrLfKNF5hkLSPcxP8sXdt7Qq+8fZRUGoyjNyF4H9ruUcbuki6MO l1oQUCXFJgI3TsGXWPE9eAn45vyK4eGqWNJB+WGNlq86gY7eRonlmghJsJfQmkFgTfJK wG3g== X-Gm-Message-State: AIkVDXIy0HFvVFOPVol8yYpnscQDqQZJALPa5p0EDMXn20pmoV7oT+c14+5xLqVuSCtWeQ== X-Received: by 10.194.203.5 with SMTP id km5mr21614703wjc.230.1482244411837; Tue, 20 Dec 2016 06:33:31 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id 135sm22429667wmh.14.2016.12.20.06.33.29 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 20 Dec 2016 06:33:31 -0800 (PST) Date: Tue, 20 Dec 2016 14:33:00 -0000 From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC master/7.12.1] Don't propagate C++ exceptions across readline using SjLj on SjLj-based exception unwinding Message-ID: <20161220143308.GC18061@E107787-LIN> References: <1482158537-17839-1-git-send-email-yao.qi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00353.txt.bz2 On 16-12-20 11:49:58, Pedro Alves wrote: > > > > I dig into libcc/unwind-sjlj.c and gcc/except.c, but I still > > don't find much clue. This patch fixes this issue by not propagating > > the exception via setjmp/longjmp if __USING_SJLJ_EXCEPTIONS__. > > I think I have a working approach that isn't specific to sjlj > exceptions, which I'd prefer. I.e., use "noexcept", to make > the compiler understand that the function doesn't throw, and hence > doesn't need to issue _Unwind_SjLj_Register / _Unwind_SjLj_Unregister > calls. That seems to do the trick. I tried both -O0 and -O2 (with > GCC trunk). Does this work for you too? Yes, it is better. I wanted to let gcc not to generate _Unwind_SjLj_Unregister calls, but I failed to find "noexcept" does the trick. The patch works for me. -- Yao (齐尧)