From f1b13d7ed363cda767dc51f0a509da1ccdedfb5c Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Sun, 5 Jan 2020 20:02:39 +0100 Subject: [PATCH] The LLVM error code bug was resolved (#711) We already updated the other posts in https://github.com/phil-opp/blog_os/pull/644 but forgot to update this post --- .../content/second-edition/posts/05-cpu-exceptions/index.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/blog/content/second-edition/posts/05-cpu-exceptions/index.md b/blog/content/second-edition/posts/05-cpu-exceptions/index.md index 840117a6..493c6bbb 100644 --- a/blog/content/second-edition/posts/05-cpu-exceptions/index.md +++ b/blog/content/second-edition/posts/05-cpu-exceptions/index.md @@ -193,12 +193,6 @@ In the `x86_64` crate, the interrupt stack frame is represented by the [`Interru [`InterruptStackFrame`]: https://docs.rs/x86_64/0.8.1/x86_64/structures/idt/struct.InterruptStackFrame.html -Note that there is currently [a bug in LLVM] that leads to wrong error code arguments. The cause of the issue is already known and a solution is [being worked on]. - -[a bug in LLVM]: https://github.com/rust-lang/rust/issues/57270 -[being worked on]: https://reviews.llvm.org/D56275 - - ### Behind the Scenes The `x86-interrupt` calling convention is a powerful abstraction that hides almost all of the messy details of the exception handling process. However, sometimes it's useful to know what's happening behind the curtain. Here is a short overview of the things that the `x86-interrupt` calling convention takes care of: