search for: __gxx_personaltity_v0

...the frame of the function calling __CxxThrow, and it has to stay alive until control leaves the catch block receiving the exception. This is different from Itanium, where the exception object is constructed in heap memory and the pointer is saved in TLS. If this were not the case, we'd use the __gxx_personaltity_v0-style landingpad approach and make a new personality variant that understands MS RTTI. We could try to do all this outlining in Clang, but that blocks a lot of LLVM optimizations. Any object with a destructor (std::string) is now escaped into the funclet that calls the destructor, and simple trans...

..._CxxThrow, and it has to stay alive until control leaves the catch block >> receiving the exception. >> This is different from Itanium, where the exception object is constructed >> in heap memory and the pointer is saved in TLS. If this were not the case, >> we'd use the __gxx_personaltity_v0-style landingpad approach and make a new >> personality variant that understands MS RTTI. >> > > I'm surprised, I really want to check this myself later this week. I > always thought that MSVCRT always copied your exception object because I > have always seen it invoking...

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,