x86-interrupt calling convention leads to wrong error code in debug mode

[phil-opp]

When using the x86-interrupt calling convention for an exception with error code, the error code is wrong in debug mode. I checked the assembly code and it seems like it loads the first field of the exception stack frame instead of the error code, i.e. it is off by 8 bytes, so this seems to be a bug in LLVM. The interesting thing is that the error code is correct in release mode.

It worked correctly with nightly (9389e23a8 2017-12-31), so it is a regression. I'm currently trying different Rust versions to find out when the problem was introduced:

Nightly	Works?
(9389e23 2017-12-31)	Yes
(8ccab7e 2018-01-31)	Yes
(bd98fe0 2018-02-06)	Yes
(3bcda48 2018-02-09)	Yes
(45fba43 2018-02-10)	No
(b8398d9 2018-02-11)	No
(4d2d3fc 2018-02-13)	No
(0ff9872 2018-02-28)	No
(1ffb321 2018-05-31)	No
(f4a421e 2018-12-13)	No

Edit: The problem was introduced between the 2018-02-09 and the 2018-02-10 nightly. These are the relevant commits: 3bcda48...45fba43. I think it was most likely the upgrade to LLVM 6 in #47828, which was huge.

See phil-opp/blog_os#513 for more context.

[phil-opp]

I think I found the problem. I'm currently preparing a LLVM patch.

[phil-opp]

I submitted a patch upstream: https://reviews.llvm.org/D56275.

[phil-opp]

A patch for fixing this issue was merged to LLVM in rL354837. I'm not sure how closely Rust tracks current LLVM changes and whether it's worth a backport.

[toothbrush7777777]

@phil-opp Has this been corrected? Does it work in recent Rust nightlies?

[mati865]

LLVM 8 (the one which Rust is using) was branched in January and it haven't been backported.
Therefore it's still not fixed.

[toothbrush7777777]

@mati865 Thank you for letting me know. Do you know if there are any plans to backport the fix into Rust's copy of LLVM?

[mark-i-m]

@toothbrush7777777 IIUC we avoid doing that because maintaining the patches on our copy is a pain.

[mark-i-m]

But the fix is in the LLVM trunk branch, so it should end up in whatever the next version of LLVM is...

[phil-opp]

I thought about doing a backport PR, but the diff is quite large because the patch in rL354837 depends on the refactoring in rL351616 (so we would need to include it too). So I think it's better to wait for the next regular update of Rust's LLVM fork.

[toothbrush7777777]

So that will be LLVM 9, right? Do you have any idea when that will be finished/copied to Rust's LLVM?

[mati865]

LLVM 9 is expected to be released around September 2019, Rust may (or may not) migrate earlier.

[phil-opp]

There is now a (work in progress) pull request to update Rust to LLVM 9 at rust-lang/llvm-project#19. GitHub doesn't display all commits, so I'm not 100% sure that it contains llvm/llvm-project@2f055f0, but I see no reason why it shouldn't.

[kyrias]

(I just double checked, and the 9.0-2019-07-12 branch does indeed contain the fix.)

[mati865]

@phil-opp LLVM 9 has made it's way to nightly, could you retest and close the issue?

[phil-opp]

@mati865 Sure. I tried it with both rustc 1.38.0-nightly (bc2e84ca0 2019-07-17) and rustc 1.38.0-nightly (95b1fe560 2019-07-20). Both nightlies reported a correct error code, so the issue seems to be fixed.