This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Do not allow unwinder to terminate inferior in an inferior function call if a C++ exception handler cannot be found.
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 27 Apr 2009 09:58:08 +0100
- 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>
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