Re: throwing C++ exceptions across C frames

[Ranjit Mathew <rmathew at hotmail dot com>]

Ben Liblit wrote:
> However, if...
>
>     - the C++ "catch" code calls some C function
>     - this C function then calls back into C++ code
>     - this C++ code now throws an exception
>
> ...then the exception is not caught and the program aborts as though it 
> had run into an uncaught exception.  It appears as though stack 
> unwinding and exception dispatch will not cross over a C stack frame.
AFAICT, this seems to be a fundamental issue with DWARF-2 based
EH - if the entire call stack was not generated by g++ produced
code using DW2 EH, exception propagation aborts unceremoniously.
SJLJ EH on the other hand doesn't seem to suffer with this
problem.

The most common case on Windows is with user-defined
Windows callbacks - this is the reason why MinGW (target
"mingw32") has now switched to SJLJ.

Any insights on how to get around this?

One of the kludges I could think of was to unwind anyways
using the frame-pointer register till you reach a frame for
which you have an FDE, but it doesn't look that neat - it
assumes everyone follows the "push ebp; mov esp, ebp" style
function prologue. Moreover, it wouldn't work anyway with
-fomit-frame-pointer generated code.

This mail from Jon Olson had an interesting take on SJLJ v/s
DW2 EH and a proposal for a "better" approach:

http://gcc.gnu.org/ml/java/1999-q1/msg00016.html

As an aside, g++ generated FDEs should be padded with
DW_CFA_nop (0x00) instructions by the trailing ".align"
assembler directive - this would automatically be the
case if ".eh_frame" is emitted in a data section, but if
it is designated as a code section the target's NOP
instruction might not necessarily be encoded as a 0x00.

Sincerely Yours,
Ranjit.

--
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/