libstdc++: Add support for exception handling using the PNaClSjLjEH LLVM pass

libstdc++: Add support for exception handling using the PNaClSjLjEH LLVM pass

Extend libsupc++ with support for SJLJ (setjmp()+longjmp()-based) C++
exception handling.  The routines assume that the program has been
transformed using the PNaClSjLjEH LLVM pass, which inserts setjmp()
calls around function calls that need to handle C++ exceptions.

As noted in the comments, this will coexist with non-SJLJ (zero cost)
exception handling within the same build of libstdc++.  When SJLJ is
enabled, pnacl-ld.py will rename
__pnacl_eh_sjlj_Unwind_RaiseException() to _Unwind_RaiseException() at
link time to enable eh_pnacl.cc.

Note that this code attempts to follow the GNU C++ style.

BUG=https://code.google.com/p/nativeclient/issues/detail?id=3696
TEST=GCC torture tests; tested with PNaCl-side plumbing in pnacl-ld.py etc.

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-gcc.git;a=commit;h=e986927

[Mark Seaborn, 2013-10-24 19:47:28]

For context, redirecting _Unwind_RaiseException() to
__pnacl_eh_sjlj_Unwind_RaiseException() will be done here:
https://codereview.chromium.org/38103003/diff/70002/pnacl/support/bitcode/sjl...

[Derek Schuff, 2013-10-24 20:41:17]

just an update; I am looking at this and it seems mostly ok but I'm still trying
to follow through some of the surrounding libstdc++ code. While I'm doing that
would be an excellent time for you to add the documentation you put in the last
CL into the design doc, and then add a description of what the runtime does
(which isn't really described here either, other than in the form of the code
itself)

https://codereview.chromium.org/27341005/diff/53001/libstdc++-v3/libsupc++/eh...
File libstdc++-v3/libsupc++/eh_pnacl.cc (right):

https://codereview.chromium.org/27341005/diff/53001/libstdc++-v3/libsupc++/eh...
libstdc++-v3/libsupc++/eh_pnacl.cc:205: __pnacl_eh_resume (struct
_Unwind_Exception *ue_header)
why __pnacl_eh_resume and not __pnacl_eh_sjlj_Unwind_Resume?

[Mark Seaborn, 2013-10-24 21:43:53]

https://codereview.chromium.org/27341005/diff/53001/libstdc++-v3/libsupc++/eh...
File libstdc++-v3/libsupc++/eh_pnacl.cc (right):

https://codereview.chromium.org/27341005/diff/53001/libstdc++-v3/libsupc++/eh...
libstdc++-v3/libsupc++/eh_pnacl.cc:205: __pnacl_eh_resume (struct
_Unwind_Exception *ue_header)
On 2013/10/24 20:41:17, Derek Schuff wrote:
> why __pnacl_eh_resume and not __pnacl_eh_sjlj_Unwind_Resume?

My thinking here was that there is a distinction between:

 * _Unwind_RaiseException() etc., which are called from libstdc++;
 * __pnacl_eh_resume(), calls to which are generated from LLVM "resume"
instructions by the PNaClSjLjEH pass.

In the first case, the symbol name *must* be "_Unwind_RaiseException".  The
caller is existing libsupc++ code that expects to call libgcc_eh.  I'm just
adding the "__pnacl_eh_sjlj" prefix so that SJLJ and non-SJLJ versions can
coexist in the same build of libstdc++.  (And this file does the work of
'removing' the suffix:
https://codereview.chromium.org/38103003/diff/70002/pnacl/support/bitcode/sjl...)

In the second case, the caller is not someone who was expecting to call
libgcc_eh.  It just happens that __pnacl_eh_resume()'s interface is the same as
_Unwind_Resume(), but the interfaces didn't have to be the same.  We never
define an "_Unwind_Resume" symbol.

Maybe this reason is tenuous.  I could go back and change PNaClSjLjEH to use the
name "__pnacl_eh_sjlj_Unwind_Resume" (or "_Unwind_Resume") if you prefer.  If
so, I should probably rename "__pnacl_eh_stack" to "__pnacl_eh_sjlj_stack" too.

[Mark Seaborn, 2013-10-28 21:05:09]

I've added more to the comments, as we discussed.

[Derek Schuff, 2013-10-28 22:14:45]

this is definitely better. the only other general thing I might add is that
there's a lot of mention of adjusting the exception pointer, but nothing about
what that means (at least until when __pnacl_eh_sjlj_Unwind_RaiseException talks
about how Unwind_RaiseException calls back into libsupc++ to do it).

https://codereview.chromium.org/27341005/diff/133001/libstdc++-v3/libsupc++/e...
File libstdc++-v3/libsupc++/eh_pnacl.cc (right):

https://codereview.chromium.org/27341005/diff/133001/libstdc++-v3/libsupc++/e...
libstdc++-v3/libsupc++/eh_pnacl.cc:136: // Search for a stack frame that will
handle the given exception.
add the description of what the arguments mean here

[Mark Seaborn, 2013-10-29 00:01:36]

On 28 October 2013 15:14, <dschuff@chromium.org> wrote:

> this is definitely better. the only other general thing I might add is that
> there's a lot of mention of adjusting the exception pointer, but nothing
> about
> what that means (at least until when __pnacl_eh_sjlj_Unwind_**RaiseException
> talks
> about how Unwind_RaiseException calls back into libsupc++ to do it).
>

OK, added explanation of pointer adjusting (which is upcasting to the type
expected by the catch() block).


>
>
https://codereview.chromium.org/27341005/diff/133001/libstdc++-v3/libsupc++/e...
> File libstdc++-v3/libsupc++/eh_**pnacl.cc (right):
>
> https://codereview.chromium.**org/27341005/diff/133001/**
>
libstdc++-v3/libsupc++/eh_**pnacl.cc#newcode136<https://codereview.chromium.org/27341005/diff/133001/libstdc++-v3/libsupc++/eh_pnacl.cc#newcode136>
> libstdc++-v3/libsupc++/eh_**pnacl.cc:136: // Search for a stack frame that
> will handle the given exception.
> add the description of what the arguments mean here
>

Done.

Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/groups/opt_out.

[Derek Schuff, 2013-10-29 00:03:36]

lgtm

[Mark Seaborn, 2013-10-30 03:17:56]

Committed patchset #5 manually as re986927 (presubmit successful).