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: 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()
$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.


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