From 844d739379ffdea6a7ede88365ec6e21a725bbf5 Mon Sep 17 00:00:00 2001 From: Ahmed Charles Date: Mon, 13 Feb 2017 05:24:59 -0800 Subject: [PATCH] =?UTF-8?q?Fix=20typo=20in=20=E2=80=9CReturning=20from=20E?= =?UTF-8?q?xceptions=E2=80=9D=20(#285)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- blog/post/11-returning-from-exceptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/post/11-returning-from-exceptions.md b/blog/post/11-returning-from-exceptions.md index d15526a5..ef08e29e 100644 --- a/blog/post/11-returning-from-exceptions.md +++ b/blog/post/11-returning-from-exceptions.md @@ -121,7 +121,7 @@ The `iretq` instruction is the one and only way to return from exceptions and is [amd-manual]: https://support.amd.com/TechDocs/24594.pdf -IRETQ restores `rip`, `cs`, `rflags`, `rsp`, and `cs` from the values saved on the stack and thus continues the interrupted program. The instruction does not handle the optional error code, so it must be popped from the stack before. +IRETQ restores `rip`, `cs`, `rflags`, `rsp`, and `ss` from the values saved on the stack and thus continues the interrupted program. The instruction does not handle the optional error code, so it must be popped from the stack before. We see that `iretq` treats the stored instruction pointer as return address. For most exceptions, the stored `rip` points to the instruction that caused the fault. So by executing `iretq`, we restart the failing instruction. This makes sense because we should have resolved the exception when returning from it, so the instruction should no longer fail (e.g. the accessed part of the memory mapped file is now present in memory).