michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-17 06:47:49 +00:00
Code Issues Projects Releases Wiki Activity

Use gutenberg's syntax for internal links

Browse Source
This commit is contained in:
Philipp Oppermann
2017-05-03 19:34:56 +02:00
parent 7744a08212
commit 3f51f3c61d
11 changed files with 52 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
blog/content/posts/09-handling-exceptions/index.md
View File

@@ -193,7 +193,7 @@ The `x86-interrupt` calling convention is a powerful abstraction that hides almo
If you are interested in more details: We also have a series of posts that explains exception handling using [naked functions] linked [at the end of this post][too-much-magic].
[naked functions]: https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md
[too-much-magic]: {{% relref "#too-much-magic" %}}
[too-much-magic]: #too-much-magic
## Implementation
Now that we've understood the theory, it's time to handle CPU exceptions in our kernel. We start by creating a new `interrupts` module:
@@ -227,7 +227,7 @@ The breakpoint exception is commonly used in debuggers: When the user sets a bre
For our use case, we don't need to overwrite any instructions (it wouldn't even be possible since we [set the page table flags] to read-only). Instead, we just want to print a message when the breakpoint instruction is executed and then continue the program.
[set the page table flags]: {{% relref "07-remap-the-kernel.md#using-the-correct-flags" %}}
[set the page table flags]: ./posts/07-remap-the-kernel/index.md#using-the-correct-flags
So let's create a simple `breakpoint_handler` function and add it to our IDT:
@@ -459,7 +459,7 @@ The documentation of the [`Idt`] struct and the [OSDev Wiki][osdev wiki exceptio
## Too much Magic?
The `x86-interrupt` calling convention and the [`Idt`] type made the exception handling process relatively straightforward and painless. If this was too much magic for you and you like to learn all the gory details of exception handling, we got you covered: Our [“Handling Exceptions with Naked Functions”] series shows how to handle exceptions without the `x86-interrupt` calling convention and also creates its own `Idt` type. Historically, these posts were the main exception handling posts before the `x86-interrupt` calling convention and the `x86_64` crate existed.
[“Handling Exceptions with Naked Functions”]: {{% relref "handling-exceptions-with-naked-fns.html" %}}
[“Handling Exceptions with Naked Functions”]: /extra/handling-exceptions-with-naked-fns
## What's next?
We've successfully caught our first exception and returned from it! The next step is to add handlers for other common exceptions such as page faults. We also need to make sure that we never cause a [triple fault], since it causes a complete system reset. The next post explains how we can avoid this by correctly catching [double faults].