From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 1A2503858D39 for ; Sun, 4 Jul 2021 04:27:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A2503858D39 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34242) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lztj0-0004jp-58; Sun, 04 Jul 2021 00:27:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3492 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lztiz-0001nv-KI; Sun, 04 Jul 2021 00:27:21 -0400 Date: Sun, 04 Jul 2021 07:27:26 +0300 Message-Id: <83bl7iitzl.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: tom@tromey.com, gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Sat, 3 Jul 2021 23:52:28 +0100) Subject: Re: [PATCH 1/5] gdb: terminate upon receipt of SIGFPE References: <09f2a7410a838d8480f014a45f83c08684a10145.1625223527.git.andrew.burgess@embecosm.com> <83a6n4kjcn.fsf@gnu.org> <87y2aooaad.fsf@tromey.com> <7aae32e5-73e7-7e71-e4e9-a2d6bed5347c@palves.net> <83wnq7j54g.fsf@gnu.org> <83eecfi7cy.fsf@gnu.org> X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 04:27:24 -0000 > From: Pedro Alves > Cc: tom@tromey.com, gdb-patches@sourceware.org > Date: Sat, 3 Jul 2021 23:52:28 +0100 > > >> -fnon-call-exceptions > >> Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support > >> that does not exist everywhere. Moreover, it only allows trapping instructions to throw exceptions, i.e. memory references > >> or floating point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as SIGALRM. > >> > >> I don't know how portable that is, but I think the Ada and Go frontends rely > >> on it, so it's probably solid. > > > This is better than crashing, I think. > > > > We can't do the usual internal_error query in the signal handler, though, > as that's non-async-signal safe, recurses into readline, can deadlock, etc. All we can > do is throw. Which means that at the catch site / top level back in mainline code, > we lost the context of the bug that led to the signal. At least some of the context could be passed via the exception itself, no? > So I think we'll still want to print > a backtrace like in Andrew's patch, and then if GDB is built with -fnon-call-exceptions, throw > an exception from the signal handler, otherwise, let the default signal action > run after printing the backtrace (i.e., terminate). So it seems that "throw from signal > handler" work could be done in a separate patch. Andrew's patch is already an improvement, > because today you just get GDB stuck in an infinite loop. Do you agree? I didn't object to installing the patch, I just wondered whether terminating is the only feasible way we have to handle these situations.