This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: C++ exceptions catching through GDB-patched .eh_frame
On Thu, 11 Dec 2008 11:57:55 +0100, Phil Muldoon wrote:
>> the branches discussed are:
>> archer-pmuldoon-exception-rewind Recover from fatal signals delivered
>> via C++ exceptions in an inferior
>> function call
>
> ... this branch is completed, with a test-case and a review. I've no
> plans to work on it further at the moment. (And reading down your email,
> the eh_frame approach won't work here anyway).
The .eh_frame would work for it :-) but I agree it may not be worth the effort
as it would have exactly the same functionality as with std::terminate().
Still it would be more compatible as future libgcc unwinding implementation may
IMO for example call exit() instead of std::terminate(). But the .eh_frame
structure can be also changed (but only with a new major release of libgcc) so
it is also not an universal solution.
>> (1) I assumed during an inferior call the unwinder will jump into a catch()
>> handler registered even above the dummy frame (the point where the
>> inferior call was started). This is not true, unwinder always stops at
>> the dummy frame and does not continue the unwinding (calls
>> std::terminate() there).
>>
>
> Yeah, the dummy frame dismantles the unwinder's approach to finding the
> exception handler. It only looks in the dummy frame, and nowhere else
> (it can't look anywhere else as GDB has tinkered with the call stack).
Still the unwinding works for the frames _below_ the dummy frame. In the
former exception.C sample code:
(gdb) start
...
Temporary breakpoint 1, main () at exception.C:12
12 setbuf (stdout, NULL);
(gdb) call main()
caught
$2 = 0
(gdb) q
>> Unfortunately GDB would have to patch the existing in-memory .eh_frame
This may be tricky as GDB must not break other .eh_frames possibly sharing the
same CIE being patched. Multiple hacks may be possible, not aware which would
be most viable.
Regards,
Jan