This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [RFC] Set unwindonsignal to on by default
Jan Kratochvil wrote:
I disagree here. Creating a dummy exception handler is altering the
inferior behaviour. If the programmer decided to write her program to
handle exceptions "out-of-frame" and we - for the convenience of an
inferior function call - create dummy exception handler records
in-frame, it's close to interfering with that behaviour.
So you would like that if the GDB-called function throws an exception which
gets caught by a code we interrupted before it should get caught there?
The first - and primary - thing I would like to happen is for the
inferior not to be terminated. The mechanics of the inferior function
call, and how it builds the environment to run that call are not
advertised to the user. Also, there is no warning label that mentions
"This may kill your inferior, stock up on aspirin". Long term goal, the
effects of an inferior function call should always be contained within
the dummy frame. One might argue that inferior function calls should be
treated as hazardous as they really do fundamentally alter the execution
environment, and the effects of those alterations can leak out of the
dummy frame (the sigabrt delivery is just the most obnoxious example).
That's the entire goal of this patch; stop the inferior termination.
There is a lot more work to be done on exception handling in C++. I
totally agree there.
Anyway this patch email thread has convinced me to write up an internal
breakpoint implementation, and submit that. Can compare approaches then
In such case the following sample should IMO puts ("exception"); when I do
(gdb) p func1()
Yeah it never will, that exception handler is not even in the call stack
when run via function call. The base of the stack is the dummy frame.
but that does not happen (IMO it should not happen, IMO we should never unwind
to frames upper than the current frame while calling an inferior function from
GDB - the question is if we:
I agree ...
(1) should catch the exception while throw is unwinding the frames to find the
exception handler (as I was suggesting)
(2) or should be caught when the std::terminate gets called because no such
handler was found (you were suggesting)
(3) or should be caught when the fatal signal gets raised by std::terminate
(as currently happens)
).
I'll write up a patch that places an internal breakpoint in
std::terminate. If an exception is not caught, then the flow has to
travel here (before then calling abort, or running a user defined custom
default handler). It's a good to place to trap an errant function call.
Regards
Phil