[PATCH] D32927: [libc++] Implement exception_ptr on Windows

[Ben Craig via Phabricator via cfe-commits]

bcraig added inline comments.


================
Comment at: test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp:12
+
+// This test fails due to a stack overflow
 // XFAIL: LIBCXX-WINDOWS-FIXME
----------------
EricWF wrote:
> BillyONeal wrote:
> > FWIW it does not pass for our implementation either.
> > 
> > Note that unlike the Itanium ABI, the stack is not popped back to the catch block when handling an exception (because SEH can act like a signal handler and say EXCEPTION_CONTINUE_EXECUTION).
> Thanks for pointing that out! Otherwise I may have gone down a rabbit hole trying to figure it out.
Also means that MSABI doesn't need to allocate heap memory in a failure case.  That always bugged me about the Itanium ABI.  In "the real world", I don't know if stack overflows are any better, but at least, in theory, maximum stack usage could be calculated by a determined enough programmer.


================
Comment at: test/std/language.support/support.exception/propagation/current_exception.pass.cpp:10-11
 
-// exception_ptr has not been implemented on Windows
+// This test needs to be rewritten for the Windows exception_ptr semantics
+// which copy the exception each time the exception_ptr is copied.
 // XFAIL: LIBCXX-WINDOWS-FIXME
----------------
EricWF wrote:
> EricWF wrote:
> > BillyONeal wrote:
> > > We don't copy the exception each time the exception_ptr is copied -- exception_ptr models shared_ptr. See: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\crt\src\stl\excptptr.cpp"
> > > 
> > > We do make a copy when making the initial exception_ptr.
> > Ah thanks for the clarification. So `std::current_exception()` always returns a different copy.
> >  exception_ptr models shared_ptr. 
> 
> Oh fudge me, it not only models it but it actually uses MSVC's `shared_ptr` implementation. This seems so much sketchier now.
You may want to pursue your long term plan instead.

Rather than use the msvcprt functions, dig into the underlying SEH structures, find the pointer to the exception, and work from there.

Headers in the older crt source have a lot of useful information, and that may be useful enough to get things going.

The blog mentions where to fine one of those useful headers (ehdata.h):
http://workblog.pilin.name/2014/03/decoding-parameters-of-thrown-c.html
"Welcome - ehdata.h. This header appears only in VS2012 and VS2013 (see "%Program Files (x86)%\Microsoft Visual Studio 12.0\VC\crt\src\ehdata.h"):"

The other useful header is mtdll.h.  I found it in my local msvc 9.0 install, but didn't find it in my msvc-14.0 install.  I don't have 10.0, 11.0, or 12.0 installed locally right now to see if mtdll.h is present in any of those.  mtdll.h describes the layout of _tiddata, a thread local data store for the CRT.  The interesting fields there are void *_curexception;  and void *_curcontext;.



https://reviews.llvm.org/D32927