-
Notifications
You must be signed in to change notification settings - Fork 13.4k
x86-interrupt calling convention leads to wrong error code in debug mode #57270
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I think I found the problem. I'm currently preparing a LLVM patch. |
I submitted a patch upstream: https://reviews.llvm.org/D56275. |
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. |
@phil-opp Has this been corrected? Does it work in recent Rust nightlies? |
LLVM 8 (the one which Rust is using) was branched in January and it haven't been backported. |
@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? |
@toothbrush7777777 IIUC we avoid doing that because maintaining the patches on our copy is a pain. |
But the fix is in the LLVM trunk branch, so it should end up in whatever the next version of LLVM is... |
So that will be LLVM 9, right? Do you have any idea when that will be finished/copied to Rust's LLVM? |
LLVM 9 is expected to be released around September 2019, Rust may (or may not) migrate earlier. |
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. |
(I just double checked, and the |
@phil-opp LLVM 9 has made it's way to nightly, could you retest and close the issue? |
@mati865 Sure. I tried it with both |
Uh oh!
There was an error while loading. Please reload this page.
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: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.
The text was updated successfully, but these errors were encountered: