From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60181 invoked by alias); 20 Dec 2016 11:50:05 -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 60146 invoked by uid 89); 20 Dec 2016 11:50:02 -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=rethrow, 1806, Propagate 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 11:50:01 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 4FB67C04B93F; Tue, 20 Dec 2016 11:50:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBKBnxqg032700; Tue, 20 Dec 2016 06:49:59 -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 , gdb-patches@sourceware.org References: <1482158537-17839-1-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: Date: Tue, 20 Dec 2016 11:50: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: <1482158537-17839-1-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00348.txt.bz2 On 12/19/2016 02:42 PM, Yao Qi wrote: > Nowadays, we propagate C++ exceptions across readline using > setjmp/longjmp 89525768cd086a0798a504c81fdf7ebcd4c904e1 > (Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH) > because DWARF-based unwinding can't cross C function (see > details from the commit above). However, SjLj-based exception > unwinding doesn't have such issue. Nice find. I built a sjlj-based GCC trunk here, and building GDB with that indeed triggers this. > > What is more, looks longjmp may break the SjLj-based exception > handling, because _Unwind_SjLj_Unregister, which is put the exit > of function, is not executed due to longjmp. > > (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 ... > > 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? >From fd8544c25b0f383fcc9517687a38c538d91e53c1 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 20 Dec 2016 11:26:36 +0000 Subject: [PATCH] noexcept --- gdb/event-top.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) 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