From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106189 invoked by alias); 20 Dec 2016 16:25:39 -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 106132 invoked by uid 89); 20 Dec 2016 16:25:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=7.12, H*f:sk:fdfc0c0 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 ESMTP; Tue, 20 Dec 2016 16:25:28 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 62F0080E4A; Tue, 20 Dec 2016 16:25:27 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBKGPQ8h031176; Tue, 20 Dec 2016 11:25:26 -0500 Subject: Re: [RFC master/7.12.1] Don't propagate C++ exceptions across readline using SjLj on SjLj-based exception unwinding To: Yao Qi References: <1482158537-17839-1-git-send-email-yao.qi@linaro.org> <20161220143308.GC18061@E107787-LIN> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0dfbf8b3-7066-2bc0-1af2-0f720b1398c8@redhat.com> Date: Tue, 20 Dec 2016 16:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161220143308.GC18061@E107787-LIN> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00356.txt.bz2 On 12/20/2016 02:33 PM, Yao Qi wrote: > 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. Great, I've applied it to master now, like below. Will apply to the 7.12 branch in a moment. >From 2693a26216c329bd7ec2aae7743409f572de4fa5 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 20 Dec 2016 15:46:44 +0000 Subject: [PATCH] Fix longjmp across readline w/ --enable-sjlj-exceptions toolchains Nowadays, GDB propagates C++ exceptions across readline using setjmp/longjmp 89525768cd08 ("Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH") because DWARF-based unwinding can't cross C functions compiled without -fexceptions (see details from the commit above). Unfortunately, toolchains that use SjLj-based C++ exceptions got broken with that fix, because _Unwind_SjLj_Unregister, which is put at the exit of a function, is not executed due to the longjmp added by that commit. (gdb) [New Thread 2936.0xb80] kill Thread 1 received signal SIGSEGV, Segmentation fault. 0x03ff662b in ?? () top?bt 15 #0 0x03ff662b in ?? () #1 0x00526b92 in stdin_event_handler (error=0, client_data=0x172ed8) at ../../binutils-gdb/gdb/event-top.c:555 #2 0x00525a94 in handle_file_event (ready_mask=, file_ptr=0x3ff5cb8) at ../../binutils-gdb/gdb/event-loop.c:733 #3 gdb_wait_for_event (block=block@entry=1) at ../../binutils-gdb/gdb/event-loop.c:884 #4 0x00525bfb in gdb_do_one_event () at ../../binutils-gdb/gdb/event-loop.c:347 #5 0x00525ce5 in start_event_loop () at ../../binutils-gdb/gdb/event-loop.c:371 #6 0x0051fada in captured_command_loop (data=0x0) at ../../binutils-gdb/gdb/main.c:324 #7 0x0051cf5d in catch_errors ( func=func@entry=0x51fab0 , func_args=func_args@entry=0x0, errstring=errstring@entry=0x7922bf "", mask=mask@entry=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:236 #8 0x00520f0c in captured_main (data=0x328feb4) at ../../binutils-gdb/gdb/main.c:1149 #9 gdb_main (args=args@entry=0x328feb4) at ../../binutils-gdb/gdb/main.c:1159 #10 0x0071e400 in main (argc=1, argv=0x171220) at ../../binutils-gdb/gdb/gdb.c:32 Fix this by making the functions involved in setjmp/longjmp as noexcept, so that the compiler knows it doesn't need to emit the _Unwind_SjLj_Register / _Unwind_SjLj_Unregister calls for C++ exceptions. Tested on x86_64 Fedora 23 with: - GCC 5.3.1 w/ DWARF-based exceptions. - GCC 7 built with --enable-sjlj-exceptions. gdb/ChangeLog: 2016-12-20 Pedro Alves Yao Qi PR gdb/20977 * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New noexcept function, factored out from ... (gdb_rl_callback_read_char_wrapper): ... this. (gdb_rl_callback_handler): Mark noexcept. --- gdb/ChangeLog | 9 +++++++++ gdb/event-top.c | 23 ++++++++++++++++++----- 2 files changed, 27 insertions(+), 5 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 233a43c..5f0e6fe 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,12 @@ +2016-12-20 Pedro Alves + Yao Qi + + PR gdb/20977 + * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New + noexcept function, factored out from ... + (gdb_rl_callback_read_char_wrapper): ... this. + (gdb_rl_callback_handler): Mark noexcept. + 2016-12-20 Antoine Tremblay * .dir-locals.el: Set c++ mode for the directory and set indent diff --git a/gdb/event-top.c b/gdb/event-top.c index acf8474..fa58def 100644 --- a/gdb/event-top.c +++ b/gdb/event-top.c @@ -157,10 +157,12 @@ void (*after_char_processing_hook) (void); sjlj-based TRY/CATCH mechanism, which knows to handle multiple levels of active setjmp/longjmp frames, needed in order to handle the readline callback recursing, as happens with e.g., secondary - prompts / queries, through gdb_readline_wrapper. */ + prompts / queries, through gdb_readline_wrapper. This must be + noexcept in order to avoid problems with mixing sjlj and + (sjlj-based) C++ exceptions. */ -static void -gdb_rl_callback_read_char_wrapper (gdb_client_data client_data) +static struct gdb_exception +gdb_rl_callback_read_char_wrapper_noexcept () noexcept { struct gdb_exception gdb_expt = exception_none; @@ -180,6 +182,15 @@ gdb_rl_callback_read_char_wrapper (gdb_client_data client_data) } END_CATCH_SJLJ + return gdb_expt; +} + +static void +gdb_rl_callback_read_char_wrapper (gdb_client_data client_data) +{ + struct gdb_exception gdb_expt + = gdb_rl_callback_read_char_wrapper_noexcept (); + /* Rethrow using the normal EH mechanism. */ if (gdb_expt.reason < 0) throw_exception (gdb_expt); @@ -187,10 +198,12 @@ gdb_rl_callback_read_char_wrapper (gdb_client_data client_data) /* GDB's readline callback handler. Calls the current INPUT_HANDLER, and propagates GDB exceptions/errors thrown from INPUT_HANDLER back - across readline. See gdb_rl_callback_read_char_wrapper. */ + across readline. See gdb_rl_callback_read_char_wrapper. This must + be noexcept in order to avoid problems with mixing sjlj and + (sjlj-based) C++ exceptions. */ static void -gdb_rl_callback_handler (char *rl) +gdb_rl_callback_handler (char *rl) noexcept { struct gdb_exception gdb_rl_expt = exception_none; struct ui *ui = current_ui; -- 2.5.5