This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]