[llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)

Wed Apr 1 13:19:52 PDT 2020

Resending; I accidentally dropped llvm-dev.

-Eli

From: Eli Friedman
Sent: Wednesday, April 1, 2020 1:01 PM
To: Ten Tzen <tentzen at microsoft.com>
Cc: aaron.smith at microsoft.com
Subject: RE: [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)

This looks like it outlines the implementation pretty well.

For goto in finally, why are you inventing a completely new mechanism for handling this sort of construct?  What makes this different from our existing handling of goto out of catch blocks?  Maybe there's something obvious here I'm missing, but it looks like essentially the same problem, and I don't see any reason why we can't use the existing solution.

For hardware exceptions, the proposal seems to have big fundamental problems.  I see two basic problems:

How do you actually generate an exception?  In general, UB means the program can do anything.  So unless you define some rule that says otherwise, the only defined way to trigger an exception is using Windows API calls.  If you want something else, we need to define new rules.  At the C level, we need to redefine some specific constructs to trigger an exception instead of UB.  And at the IR level, we need to annotate specific IR instructions in a way that passes can reasonably check, and add new LangRef rules describing those semantics.  I mean, you can try to sort of hand-wave this and say it should "just work" if code happens to trigger a hardware exception.  But if there aren't actually any rules, I'm afraid we'll end up with an infinitely long tail of "optimization X breaks some customer's code, so add a hack to disable it in EHa mode".

If we're not modeling the control flow implied by an exception, how do we ensure that local variables and SSA registers have the right values when the exception is caught?  Sure, invoke is clunky, but it's at least makes control flow well-defined.  Adding "volatile" to every IR load and store instruction, including accesses to local variables, seems terrible for both optimization and correctness.  Our handling of setjmp is already a complete mess; I don't want to add another way for unmodeled control flow to break code.  (See also http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt, for a proposal to make invoke less messy.)

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Ten Tzen via llvm-dev
Sent: Tuesday, March 31, 2020 9:13 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Cc: aaron.smith at microsoft.com<mailto:aaron.smith at microsoft.com>
Subject: [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)

Hi, all,

The intend of this thread is to complete the support for Windows SEH.
Currently there are two major missing features:  Jumping out of a _finally and Hardware exception handling.

The document below is my proposed design and implementation to fully support SEH on LLVM.
I have completely implemented this design on a branch in repo:  https://github.com/tentzen/llvm-project<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftentzen%2Fllvm-project&data=02%7C01%7Ctentzen%40microsoft.com%7Ced638e497aa74798b3f808d7d5e46775%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213049272295023&sdata=Pd6gK%2B7JsIlfcyJLB%2FajWKdrbgqsITsseBfeB2Z5lgg%3D&reserved=0>.
It now passes MSVC's in-house SEH suite.

Sorry for this long write-up.  For better readability, please read it on https://github.com/tentzen/llvm-project/wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftentzen%2Fllvm-project%2Fwiki&data=02%7C01%7Ctentzen%40microsoft.com%7Ced638e497aa74798b3f808d7d5e46775%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213049272305020&sdata=SN9XBN6InU79U%2FEXnReyi9H1uPbVwTHgXhMkKODnA%2FM%3D&reserved=0>

Special thanks to Joseph Tremoulet for his earlier comments and suggestions.

Note: I just subscribed llvm-dev, probably not in the list yet.  So please reply with my email address (tentzen at microsoft.com<mailto:tentzen at microsoft.com>) explicitly in To-list.
Thanks,

--Ten

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