Support exception handling on windows #6419

RX14 · 2018-07-20T19:46:49Z

This was a tough one, but I learned a lot along the way and I'm glad I accomplished it.

asterite · 2018-07-20T19:58:20Z

Wat? You are glad you accomplished it?? You are ****ing amazing, Chris!

bararchy · 2018-07-20T20:17:55Z

My hero!
Great work 🎉

ukd1 · 2018-07-20T20:22:22Z

@RX14 💯 💯 💯 💯 💯 💯 💯

RX14 · 2018-07-20T20:47:15Z

A lot of this work was @bcardiff and @txe, I stand on the shoulders of giants.

straight-shoota · 2018-07-22T19:17:30Z

I used a compiler with this patch to compile my local branch with Windows library bindings. It didn't break anything, but the specs don't contain any expectations about exceptions, because that didn't work until now. But I'll work on that.

I also compiled crinja's spec suite. It's one of the largest Crystal projects I know and there are quite a number of exception raised and rescued. And it worked fine 👍 Not all specs passed (which was to be expected), but none fails because of an error in exception handling.

RX14 · 2018-07-22T21:44:51Z

@straight-shoota thats fantastic. I wouldn't be surprised if there's still quite a few edge cases in here though. The key hint is usually an "invalid instruction" segfault (llvm adds a ud2 instruction at the end of catch blocks where it thinks it should be unreachable) or a module validation failure.

bcardiff

This is great @RX14. I am still OOF one more week, but it was too much temptation to go through this PR 😅 .

There are some questions, doubts and ideas on how to avoid loosing track of the decisions and knowledge needed to understand this change.

bcardiff · 2018-07-24T10:45:28Z

src/compiler/crystal/codegen/llvm_builder_helper.cr

@@ -76,7 +76,35 @@ module Crystal
      builder.inbounds_gep ptr, index0, index1, name
    end

-    delegate ptr2int, int2ptr, and, or, not, call, bit_cast,
+    def call(func, name : String = "")


Is there a reason why the handling of the funclet operand bundle can't be done in codegen_call_or_invoke? That would leave the plain delegation in place and avoid duplication.

Because there's too many places where codegen generates a call outside of codegen_call_or_invoke. I originally had it in codegen_call_or_invoke but I didnt feel like duplicating funclet code in the 50 other places that generate calls (think codegen for constants, there's way more though)

bcardiff · 2018-07-24T10:58:24Z

src/compiler/crystal/codegen/codegen.cr

@@ -613,6 +623,12 @@ module Crystal

      if return_phi = context.return_phi
        return_phi.add @last, node_type
+      elsif catch_pad = @catch_pad


So, returns inside a catch_pad section needs to be handled different. I fail to see that the current specs handle return with values. I neither find specs added on this topic, so maybe is something to add in the suite. WDYT?

Yeah, I didn't really look at the spec suite since it's impossible to run the compiler spec suite on windows yet because the compiler depends on a bunch of stuff thats not ported.

bcardiff · 2018-07-24T11:00:53Z

src/compiler/crystal/codegen/crystal_llvm_builder.cr

@@ -41,8 +41,14 @@ module Crystal
      value
    end

-    def printf(format, args = [] of LLVM::Value)
-      call @printf, [global_string_pointer(format)] + args
+    def printf(format, args = [] of LLVM::Value, catch_pad = nil)


call to printf do really need to be handled with the funclet? Up to know the call was never replaced by an invoke, so it was assumed to never raise AFAIK.

every call inside a catch pad needs a funclet. This is not about call/invoke and @rescue_block, it's about @catch_pad which is a totally different concern and semantic. This is about telling LLVM which method calls are inside the "catch block", and it applies to every single method call. @rescue_block is about codegenning invoke instructions, and it only matters for calls that raise.

Ok. I also missed this was inside the builder, outside the codegen where the handling of the operand bundle is already handled.

bcardiff · 2018-07-24T11:11:26Z

src/compiler/crystal/codegen/exception.cr

@@ -195,6 +203,153 @@ class Crystal::CodeGenVisitor
    false
  end

+  private def codegen_windows_seh(node : ExceptionHandler)


I think there should be some comments here explaining how the exception data is handled. I know it comes from documentation of llvm seh and trial an error. But there are some decisions w.r.t. how exception is encoded as void* that would help future readers. Also some basic examples of the result in llvm-ir would be great for documentation IMO (l tried to do that at for overflow here in the past).

And I am tempted to suggest some comment or extraction of common parts with the codegen_landing_pad. The handling of multiple ensures is shared. Maybe a strategy struct can be used to encapsulate custom logic for pads vs seh, leaving the existing comments visit(node : ExceptionHandler)/codegen_landing_pad that goes into the details of the handling of the AST. The only real value of this would be to help the reader to understand separate the concepts that are together in this code.

I'll definitely look at how to possibly abstract this, if not I'll definitely add some comments.

bcardiff · 2018-07-24T11:18:29Z

src/raise.cr

-    exception.inspect_with_backtrace(STDERR)
-    LibC.exit(1)
-  end
+    {% if flag?(:debug_raise) %}


I would add a TODO note to remote the whole puts here, or just leave it commented for a while.

I don't see why we can't leave the flag in indefinitely.

If it's going to stay, then it needs to be supported in the other platforms.

Oh yeah, my bad.

bcardiff · 2018-07-24T11:21:29Z

src/compiler/crystal/codegen/primitives.cr

@@ -912,4 +914,84 @@ class Crystal::CodeGenVisitor

    node.value
  end
+
+  def void_ptr_type_descriptor


I'm glad code snippets end up been useful :-). Thanks for tidying them up a bit.

hanyuone · 2018-08-01T07:47:31Z

Should this also be on 0.26.0 @bcardiff?

RX14 · 2018-08-01T15:51:42Z

Pushed an update which merges the windows and linux exception handling code and improves the comments.

bcardiff · 2018-08-04T20:32:58Z

src/compiler/crystal/codegen/exception.cr

    rescue_block = new_block "rescue"

    node_rescues = node.rescues
    node_ensure = node.ensure
    node_else = node.else
    rescue_ensure_block = nil

-    # Here we transform this:


I would say that this whole comment section should stay. Your additions inlines are great, but keeping this sections with numbers and later references would be ideal. They facilitate understanding the later code a lot.

Other than that LGTM.

I don't like that block comment because it's very incomplete information, and once you distill it into it's core it's just what I've written below.

Once I start thinking how to improve the comment, I just end up with repeating what i've written below

The once you distill time is decreased a lot with a nice introduction like the one that is removed. I think that the intricate nature of the code transformation deserves that kind of introduction. Just restoring those line are enough.

RX14 · 2018-08-06T15:39:05Z

Added a comment @bcardiff

Sija · 2018-08-06T15:45:31Z

src/compiler/crystal/codegen/exception.cr

    #
-    # ```
+    # ```cr


cr here is invalid (that's gfm), it better be empty (like it was before)
ditto all below

It doesn't hurt, though.

It doesn't help either (especially since it was good before that change).

who cares, the comment isn't for anyone but humans

Yeah, and humans know what cr stands for...

I agree with @Sija. It's better without the cr. But we can clean up that later (together with one more ```crystal that is somewhere in the code...)

RX14 added kind:feature topic:compiler platform:windows labels Jul 20, 2018

RX14 requested a review from bcardiff July 20, 2018 19:46

hanyuone mentioned this pull request Jul 24, 2018

Coordinate porting to Windows #5430

Open

22 tasks

RX14 mentioned this pull request Jul 24, 2018

Win exceptions #5591

Closed

bcardiff reviewed Jul 24, 2018

View reviewed changes

Support exception handling on windows

0e0e28a

RX14 force-pushed the feature/windows-exceptions branch from 0bab1bc to 0e0e28a Compare August 1, 2018 15:51

hanyuone mentioned this pull request Aug 3, 2018

Release 0.26.0 #6475

Merged

bcardiff requested changes Aug 4, 2018

View reviewed changes

bcardiff added this to the 0.26.0 milestone Aug 4, 2018

fixup! Support exception handling on windows

5cb15f0

Sija reviewed Aug 6, 2018

View reviewed changes

bcardiff approved these changes Aug 6, 2018

View reviewed changes

bcardiff merged commit 9a98613 into crystal-lang:master Aug 6, 2018

straight-shoota added this to Todo in Windows via automation Jan 8, 2019

straight-shoota moved this from Todo to Done in Windows Jan 8, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support exception handling on windows #6419

Support exception handling on windows #6419

RX14 commented Jul 20, 2018

asterite commented Jul 20, 2018

bararchy commented Jul 20, 2018

ukd1 commented Jul 20, 2018

RX14 commented Jul 20, 2018

straight-shoota commented Jul 22, 2018

RX14 commented Jul 22, 2018

bcardiff left a comment

bcardiff Jul 24, 2018

RX14 Jul 24, 2018 •

edited

bcardiff Jul 24, 2018

RX14 Jul 24, 2018 •

edited

bcardiff Jul 24, 2018

RX14 Jul 24, 2018

bcardiff Jul 24, 2018

bcardiff Jul 24, 2018

RX14 Jul 24, 2018

bcardiff Jul 24, 2018

RX14 Jul 24, 2018

bcardiff Jul 24, 2018

RX14 Jul 24, 2018

bcardiff Jul 24, 2018

hanyuone commented Aug 1, 2018 •

edited

RX14 commented Aug 1, 2018 •

edited

bcardiff Aug 4, 2018

RX14 Aug 4, 2018

bcardiff Aug 4, 2018

RX14 commented Aug 6, 2018

Sija Aug 6, 2018 •

edited

straight-shoota Aug 6, 2018

Sija Aug 6, 2018 •

edited

RX14 Aug 6, 2018 •

edited

Sija Aug 6, 2018 •

edited

bcardiff Aug 6, 2018

Support exception handling on windows #6419

Support exception handling on windows #6419

Conversation

RX14 commented Jul 20, 2018

asterite commented Jul 20, 2018

bararchy commented Jul 20, 2018

ukd1 commented Jul 20, 2018

RX14 commented Jul 20, 2018

straight-shoota commented Jul 22, 2018

RX14 commented Jul 22, 2018

bcardiff left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RX14 Jul 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RX14 Jul 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanyuone commented Aug 1, 2018 • edited

RX14 commented Aug 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RX14 commented Aug 6, 2018

Sija Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sija Aug 6, 2018 • edited

Choose a reason for hiding this comment

RX14 Aug 6, 2018 • edited

Choose a reason for hiding this comment

Sija Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RX14 Jul 24, 2018 •

edited

RX14 Jul 24, 2018 •

edited

hanyuone commented Aug 1, 2018 •

edited

RX14 commented Aug 1, 2018 •

edited

Sija Aug 6, 2018 •

edited

Sija Aug 6, 2018 •

edited

RX14 Aug 6, 2018 •

edited

Sija Aug 6, 2018 •

edited