Win64 Exception Handling #166

TurkeyMan · 2012-09-17T08:38:50Z

Seems to be moving along slowly in LLVM.
Can devs please keep this issue updated with the current state of progress?

redstar · 2012-12-07T15:06:43Z

A preliminary patch was posted here

I extended the llvm-objdump part of this patch. The last version is now committed in LLVM 3.3.

dnadlinger · 2012-12-07T15:30:44Z

That required an awful lot of staying power on your side for such a small patch… ;)

redstar · 2012-12-07T15:36:56Z

Let's view it from the other side: IMHO the code really improved from 'it works' to understandable code. :-) But there is only a handful lines left of the original patch from João....

redstar · 2013-05-16T16:12:23Z

Encouraged by the warm feedback at DConf I like to report some progress with the Win64 exception issue. :-)

With my latest LLVM changes I can throw an exception (via RaiseExcepion in _d_thow_exception) and control is transferred to _d_eh_personality. Right now I have trouble to get the pointer to the LSDA right (maybe a relocation issue). As soon as I have solved this I will send my changes to the LLVM list.

Stay tuned - I am going to crack this nut. :-)

redstar · 2013-05-17T14:58:42Z

See here: http://article.gmane.org/gmane.comp.compilers.llvm.cvs/145727

I now try to get DRuntime to handle the exception.

redstar · 2013-05-19T14:30:07Z

Here is the complete patch against LLVM 3.4 trunk. With this patch I can add Win64 SEH unwind information to all druntime and phobos modules with no failure! The LLVM test suite passes except one test.
But: there is still a bug in the generated Dwarf EH code. It always says that there is no landingpad....

dnadlinger · 2013-05-19T18:45:16Z

Can't wait to see the D test suite passing. ;)

But how would Dwarf EH be relevant here? You mean the libunwind EH interface?

redstar · 2013-05-19T18:52:49Z

No. There are 2 pieces of EH information. Base here is the unwinding information required by Win64. But part of that is the language handler specific data - which is the Dwarf EH code (the LSDA aka GCC_except_tableN).
I now try to implement ldc.eh2. :-)

dnadlinger · 2013-05-19T22:03:46Z

Ah, yes, of course.

By the way, what is plaguing me now on OS X (the file/parallelism release mode segfaults) seems to be an issue with the MC EH table generation, will post a new bug as soon as I have pushed the rest of the OS X changes.

redstar · 2013-09-17T16:35:57Z

There is slow progress: I committed the first 3 (out of 5) parts of my patch in LLVM 3.4. Part 4 is in the review queue.
But the last part is blocked by this LLVM issue: http://llvm.org/bugs/show_bug.cgi?id=16779 I started to work on this..

redstar · 2014-04-29T06:03:47Z

There are now more people interested in this stuff, especially integrating this into clang.

Here is the main review link: http://reviews.llvm.org/D3418

redstar · 2014-06-11T16:26:16Z

There is some progress. vadimcn rewrote my patch. It looks that he solved the parameter alignment, too.

Here is the main review link: http://reviews.llvm.org/D4081
There is also a patch for clang: http://reviews.llvm.org/D3419

TurkeyMan · 2014-06-12T01:07:10Z

Awesome! So, does that mean the last roadblock between MSC parity is just the VC8/PDB debuginfo?
With the exception handling, I think that's everything on the codegen side yeah?

redstar · 2014-06-12T04:55:52Z

There is still issue #463 but this is minor compared with the code generation. Yes, I hope it will happen with LLVM 3.5.

TurkeyMan · 2014-06-12T15:05:15Z

'it' will happen; you mean, CV8 debuginfo?

Trass3r · 2014-06-23T15:47:06Z

Looks like it got merged.
http://reviews.llvm.org/rL211399

redstar · 2014-06-23T16:11:16Z

Yes, the patch was merged. Really good news. There is still an issue left (begin and end of function code is always the same label) but this sounds trivial to fix. It is really a problem of the MC layer - using the GNU assembler seems to produce the correct EH tables.
I am closing this issue as soon as I have checked the functionality.

Trass3r · 2014-06-23T16:19:40Z

Yeah finally 👍
Now there's just #607 standing in my way.

redstar · 2014-06-23T16:29:35Z

It's a building block but not the final solution. E.g. #463 needs also some love.

redstar · 2014-06-23T21:06:14Z

... and the patch got reverted in r211480... :-(

TurkeyMan · 2014-06-23T22:35:20Z

Nooo! :(
Why?

dnadlinger · 2014-06-23T22:41:41Z

It regressed part of the legacy JIT tests on Win64 (LLVM has currently two JIT backends in the tree).

redstar · 2014-06-25T16:12:06Z

Patch is re-applied in r211691 with a fix for the JIT problem. Note that there is still the bug in the MC layer.

Trass3r · 2014-07-01T09:33:48Z

I guess the error message I'm getting now might be related to that MC bug.
file contains invalid .pdata contributions #609

redstar · 2014-07-02T16:13:48Z

Yes, that is the symptom described on LLVM commit list.

Trass3r · 2014-07-02T18:48:56Z

Indeed. They disabled the tables for now in clang: http://llvm.org/viewvc/llvm-project?view=revision&revision=212137

redstar · 2014-07-03T17:06:34Z

A fix was proposed, see comment of twobit at http://reviews.llvm.org/D4081

Trass3r · 2014-07-08T18:13:24Z

Works but as already commented by rnk the .xdata/.pdatas should be COMDATs.

vadimcn · 2014-07-25T01:14:37Z

cc me

Trass3r · 2014-09-04T18:28:37Z

http://reviews.llvm.org/D5181
This finally solves the pdata linker problem and also enables proper COMDAT elimination by the linker it seems. Hello world is now 392KB.

But exception handling still doesn't work in D.

extern(C) int printf(const char* fmt, ...);
void foo()
{
    printf("foo pre\n");
    throw new Exception("foo ex");
    printf("foo post\n");
}
void main()
{
    try
    {
        printf("main pre\n");
        foo();
        printf("main post\n");
    }
    catch (Exception e)
    {
        printf("exception caught: %s\n", e.toString().ptr);
    }
    finally
    {
        printf("finally\n");
    }
    printf("exit\n");
}

main pre
foo pre
Calling _d_throw_exception = 000000013FD795D0 e = 0000000001E12F80
Comparing caught object.Exception to exception 1e12f80 [email protected](5): foo ex
Comparing caught object.Exception to exception 1e12f80 [email protected](5): foo ex
finally
Calling _d_eh_resume_unwind = 000000013FD796C0 e = 0000000000000008

Trass3r · 2014-09-05T08:30:41Z

Slightly modified, in this case it reaches the catch.
@redstar Any idea what's going on there?

extern(C) int printf(const char* fmt, ...) nothrow;
void foo()
{
    printf("foo pre\n");
    throw new Exception("foo ex");
    printf("foo post\n");
}
void main()
{
    try
    {
        printf("main pre\n");
        foo();
        printf("main post\n");
    }
    catch (Exception e)
    {
        printf("catch\n");
        printf("exception caught: %s %s %d\n", e.msg.ptr, e.file.ptr, e.line);
    }
    finally
    {
        printf("finally\n");
    }
    printf("exit\n");
}

main pre
foo pre
Calling _d_throw_exception = 000000013F1C9620 e = 0000000001E82F80 [email protected](5): foo ex
Found correct landing pad 13f1c10e3 and actionOffset 1
Comparing caught object.Exception to exception 0000000001E82F80 [email protected](5): foo ex
excobj isbaseof catch_ci, flags: 1
Found correct landing pad 13f1c10e3 and actionOffset 1
Comparing caught object.Exception to exception 0000000001E82F80 [email protected](5): foo ex
excobj isbaseof catch_ci, flags: 22
catch
)¯♣ UHëÕHüýÓ 1059193040âý`HëM°HëUHì
finally
exit

Zero memory outside global GC lock

Trass3r · 2014-10-06T18:17:07Z

Some movement on the Clang front: http://article.gmane.org/gmane.comp.compilers.clang.devel/39152

redstar · 2014-10-19T00:08:49Z

With commit ldc-developers/druntime@d12cc01 both test cases from Trass3r seems to work.
@Trass3r @kinke Maybe you like to test?

redstar · 2014-10-21T05:47:54Z

Closing this issue because it works now in master with LLVM 3.6.

dnadlinger · 2014-10-21T19:24:38Z

Nice! Like, really, really nice! ;)

TurkeyMan · 2014-10-22T00:05:38Z

Ohmygawd! This is good!
So, what's the state on the very last issue remaining (CV8 debudinfo)?
Are there LLVM guys working on that too? Part of Clang's MSVC compatibility ambition?

Trass3r · 2014-10-22T06:09:42Z

Not yet. Only line tables.

klutzy mentioned this issue Sep 12, 2013

64-bit windows build. rust-lang/rust#1237

Closed

Trass3r mentioned this issue Sep 6, 2014

executable size on Win64 #669

Closed

redstar pushed a commit that referenced this issue Sep 27, 2014

Merge pull request #166 from dsimcha/master

d66d047

Zero memory outside global GC lock

kinke mentioned this issue Oct 18, 2014

core.stdc.math: full support for MSVCRT 2013+ ldc-developers/druntime#13

Merged

redstar closed this as completed Oct 21, 2014

Win64 Exception Handling #166

Win64 Exception Handling #166

Comments

TurkeyMan commented Sep 17, 2012

redstar commented Dec 7, 2012

dnadlinger commented Dec 7, 2012

redstar commented Dec 7, 2012

redstar commented May 16, 2013

redstar commented May 17, 2013

redstar commented May 19, 2013

dnadlinger commented May 19, 2013

redstar commented May 19, 2013

dnadlinger commented May 19, 2013

redstar commented Sep 17, 2013

redstar commented Apr 29, 2014

redstar commented Jun 11, 2014

TurkeyMan commented Jun 12, 2014

redstar commented Jun 12, 2014

TurkeyMan commented Jun 12, 2014

Trass3r commented Jun 23, 2014

redstar commented Jun 23, 2014

Trass3r commented Jun 23, 2014

redstar commented Jun 23, 2014

redstar commented Jun 23, 2014

TurkeyMan commented Jun 23, 2014

dnadlinger commented Jun 23, 2014

redstar commented Jun 25, 2014

Trass3r commented Jul 1, 2014

redstar commented Jul 2, 2014

Trass3r commented Jul 2, 2014

redstar commented Jul 3, 2014

Trass3r commented Jul 8, 2014

vadimcn commented Jul 25, 2014

Trass3r commented Sep 4, 2014

Trass3r commented Sep 5, 2014

Trass3r commented Oct 6, 2014

redstar commented Oct 19, 2014

redstar commented Oct 21, 2014

dnadlinger commented Oct 21, 2014

TurkeyMan commented Oct 22, 2014

Trass3r commented Oct 22, 2014