From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5932 invoked by alias); 27 Apr 2009 08:58:22 -0000 Received: (qmail 5920 invoked by uid 22791); 27 Apr 2009 08:58:21 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Apr 2009 08:58:13 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3R8wAwY024850; Mon, 27 Apr 2009 04:58:10 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3R8w9DE000805; Mon, 27 Apr 2009 04:58:10 -0400 Received: from localhost.localdomain (vpn-6-39.fab.redhat.com [10.33.6.39]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3R8w8Oj017755; Mon, 27 Apr 2009 04:58:09 -0400 Message-ID: <49F573A0.4080500@redhat.com> Date: Mon, 27 Apr 2009 08:58:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [patch] Do not allow unwinder to terminate inferior in an inferior function call if a C++ exception handler cannot be found. References: <49F17924.50300@redhat.com> <83vdouf8o2.fsf@gnu.org> In-Reply-To: <83vdouf8o2.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2009-04/txt/msg00730.txt.bz2 Eli Zaretskii wrote: >> + add_setshow_boolean_cmd ("unwind-on-terminating-exception", no_class, >> + &unwind_on_terminating_exception_p, _("\ >> +Set unwinding of stack if a std::terminate() call originates from\n\ >> +the default C++ exception handler."), _("\ >> +Show unwinding of stack if a std::terminate() call originates from\n\ >> +the default C++ exception handler."), _("\ >> > > This is not good: the first sentence of a doc string should not take > more than one screen line, because various help commands, such as > `apropos', display only the first line. How about > > Set unwinding of stack if std::terminate is called while in call dummy. > > ? > That's fine with me. I did not know that about apropos, thanks for the tip. I'll add it to my patch list. >> +The unwind on terminating exception flag lets the user determine\n\ >> +what gdb should do if a std::terminate() call is made from the\n\ >> +default exception handler.\n\ >> +The default is to unwind the frame."), >> > This doesn't tell what happens if it's set to OFF. > > I actually thought about this, but the off behaviour is just how GDB "used to be". Something like: "If the flag is set to be 'off', GDB will allow the inferior to be terminated by the default exception handler."? >> +Similarly, with a C++ program it is possible for the function you >> > > Please use C@t{++} (here and elsewhere), it looks better in the > printed manual. > > Thanks, noted and corrected. >> +call via the @code{print} or @code{call} command to generate an >> +exception that is not handled due to the constraints of the dummy >> +frame. >> > > I think ``due to the constraints of the dummy frame'' needs an > explanation. I'm quite sure many C++ programmers will not immediately > grasp the nature of the problem. > I'll add a brief narrative explaining why the unwinder can only see the dummy frame, and incorrectly infer that there are no more frames to check for an exception handler. > >> +Set unwinding of the stack if a C++ exception is raised but unhandled >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > either > exception is raised, but left unhandled > > I'll use that one, thanks. >> If set to off, @value{GDBN} the exception is delivered to >> +the default C++ exception handler. >> > > This means the debuggee will be terminated, right? If so, we should > mention that explicitly. > > Noted, and changed. > Other than that, the patch for the manual is approved. > Thanks for the swift review! Regards Phil Muldoon