Win64 Exception Handling

[TurkeyMan]

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

[redstar]

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]

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

[redstar]

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]

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]

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

I now try to get DRuntime to handle the exception.

[redstar]

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]

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]

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]

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]

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]

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]

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]

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]

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