[LLVMdev] [WinEH] A hiccup for the Windows C++ exception handling

[Kaylor, Andrew]

I made some progress this afternoon.  I now have a set of changes in my local sandbox that allows clang to pass all of the tests in the suite I’ve been using to exercise this code.

How do you feel about working these changes into trunk to establish a working baseline, even knowing that parts of this are going to be redesigned?

-Andy

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Wednesday, May 13, 2015 2:16 PM
To: Kaylor, Andrew; David Majnemer
Cc: LLVM Developers Mailing List
Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling

Basically, I'm trying to come up with a good design doc with David right now so I can mail it out. :)

On Wed, May 13, 2015 at 1:43 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Have got anything started with the dispatchblock plan?

From: Reid Kleckner [mailto:rnk at google.com<mailto:rnk at google.com>]
Sent: Wednesday, May 13, 2015 1:15 PM
To: Kaylor, Andrew
Cc: David Majnemer <david.majnemer at gmail.com<mailto:david.majnemer at gmail.com>> (david.majnemer at gmail.com<mailto:david.majnemer at gmail.com>); LLVM Developers Mailing List
Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling

On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:
So there are two issues here.

1) We need a better way to figure out which blocks should be in which handlers and properly remap the return statements in each handler accordingly.
2) We need a better way to compute the EH states.

Anyway, I’m working on these problems right now.  I’m still trying to solve the problems without redesigning our current scheme, but I don’t think this is going to be the right long term solution.

Yeah, we're on the same page. The current scheme is not the right long term solution. The SEH personality functions are not nearly as limiting. I was hoping that, like with SEH, we could completely throw away the information about try nesting and simply emit tables that are functionally correct. We knew it was theoretically impossible to always recover the nested try structure from Itanium-style landingpad IR, but now we know it is also *practically* impossible. :)

Ultimately, I think something like the dispatchblock scheme I described will work better.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150513/fc7f8bc8/attachment.html>