Win64 Exception Handling #166

Closed
TurkeyMan opened this Issue Sep 17, 2012 · 37 comments

Comments

Projects
None yet
5 participants

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

Owner

redstar commented Dec 7, 2012

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.

Owner

klickverbot commented Dec 7, 2012

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

Owner

redstar commented Dec 7, 2012

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....

Owner

redstar commented May 16, 2013

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. :-)

Owner

redstar commented May 17, 2013

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

I now try to get DRuntime to handle the exception.

Owner

redstar commented May 19, 2013

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....

Owner

klickverbot commented May 19, 2013

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

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

Owner

redstar commented May 19, 2013

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. :-)

Owner

klickverbot commented May 19, 2013

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.

@klutzy klutzy referenced this issue in rust-lang/rust Sep 12, 2013

Closed

64-bit windows build. #1237

Owner

redstar commented Sep 17, 2013

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..

Owner

redstar commented Apr 29, 2014

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

Owner

redstar commented Jun 11, 2014

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

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?

Owner

redstar commented Jun 12, 2014

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

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

Contributor

Trass3r commented Jun 23, 2014

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

Owner

redstar commented Jun 23, 2014

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.

Contributor

Trass3r commented Jun 23, 2014

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

Owner

redstar commented Jun 23, 2014

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

Owner

redstar commented Jun 23, 2014

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

Nooo! :(
Why?

Owner

klickverbot commented Jun 23, 2014

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

Owner

redstar commented Jun 25, 2014

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

Contributor

Trass3r commented Jul 1, 2014

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

Owner

redstar commented Jul 2, 2014

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

Contributor

Trass3r commented Jul 2, 2014

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

Owner

redstar commented Jul 3, 2014

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

Contributor

Trass3r commented Jul 8, 2014

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

vadimcn commented Jul 25, 2014

cc me

Contributor

Trass3r commented Sep 4, 2014

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 object.Exception@simpleEH.d(5): foo ex
Comparing caught object.Exception to exception 1e12f80 object.Exception@simpleEH.d(5): foo ex
finally
Calling _d_eh_resume_unwind = 000000013FD796C0 e = 0000000000000008
Contributor

Trass3r commented Sep 5, 2014

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 object.Exception@simpleEH.d(5): foo ex
Found correct landing pad 13f1c10e3 and actionOffset 1
Comparing caught object.Exception to exception 0000000001E82F80 object.Exception@simpleEH.d(5): foo ex
excobj isbaseof catch_ci, flags: 1
Found correct landing pad 13f1c10e3 and actionOffset 1
Comparing caught object.Exception to exception 0000000001E82F80 object.Exception@simpleEH.d(5): foo ex
excobj isbaseof catch_ci, flags: 22
catch
)¯♣ UHëÕHüýÓ 1059193040âý`HëM°HëU­Hì
finally
exit

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

Merge pull request #166 from dsimcha/master
Zero memory outside global GC lock
Contributor

Trass3r commented Oct 6, 2014

@kinke kinke referenced this issue in ldc-developers/druntime Oct 18, 2014

Merged

core.stdc.math: full support for MSVCRT 2013+ #13

Owner

redstar commented Oct 19, 2014

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

Owner

redstar commented Oct 21, 2014

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

@redstar redstar closed this Oct 21, 2014

Owner

klickverbot commented Oct 21, 2014

Nice! Like, really, really nice! ;)

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?

Contributor

Trass3r commented Oct 22, 2014

Not yet. Only line tables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment