From a8847c22efd80d34d19ffbea8017161bc0841cb0 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Wed, 4 Jan 2017 16:36:25 +0100 Subject: [PATCH] Fix broken links --- blog/post/04-printing-to-screen.md | 2 +- blog/post/07-remap-the-kernel.md | 2 +- blog/post/08-kernel-heap.md | 4 ++-- blog/post/09-catching-exceptions.md | 2 +- blog/post/10-better-exception-messages.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/blog/post/04-printing-to-screen.md b/blog/post/04-printing-to-screen.md index da95e1d4..50032009 100644 --- a/blog/post/04-printing-to-screen.md +++ b/blog/post/04-printing-to-screen.md @@ -486,7 +486,7 @@ pub static WRITER: Mutex = Mutex::new(Writer { Now we can easily print from our main function: -[Mutex::new]: https://mvdnes.github.io/rust-docs/spinlock-rs/spin/struct.Mutex.html#method.new +[Mutex::new]: https://docs.rs/spin/0.4.5/spin/struct.Mutex.html#method.new ```rust // in src/lib.rs diff --git a/blog/post/07-remap-the-kernel.md b/blog/post/07-remap-the-kernel.md index 797b84e9..c87556bc 100644 --- a/blog/post/07-remap-the-kernel.md +++ b/blog/post/07-remap-the-kernel.md @@ -1072,4 +1072,4 @@ Now that we have a (mostly) safe kernel stack and a working page table module, w [next post]: {{% relref "08-kernel-heap.md" %}} [Box]: https://doc.rust-lang.org/nightly/alloc/boxed/struct.Box.html [Vec]: https://doc.rust-lang.org/nightly/collections/vec/struct.Vec.html -[BTreeMap]: https://doc.rust-lang.org/nightly/collections/struct.BTreeMap.html +[BTreeMap]: https://doc.rust-lang.org/nightly/collections/btree_map/struct.BTreeMap.html diff --git a/blog/post/08-kernel-heap.md b/blog/post/08-kernel-heap.md index 7ef5a749..5103c530 100644 --- a/blog/post/08-kernel-heap.md +++ b/blog/post/08-kernel-heap.md @@ -330,7 +330,7 @@ check_exception old: 0xffffffff new 0xe SP=0010:0000000000116af0 CR2=0000000040000000 … ``` -Aha! It's a [page fault] (`v=0e`) and was caused by the code at `0x102860`. The code tried to write (`e=0002`) to address `0x40000000`. This address is `0o_000_001_000_000_0000` in octal, which is the `HEAP_START` address defined above. Of course it page-faults: We have forgotten to map the heap memory to some physical memory. +Aha! It's a [page fault] \(`v=0e`) and was caused by the code at `0x102860`. The code tried to write (`e=0002`) to address `0x40000000`. This address is `0o_000_001_000_000_0000` in octal, which is the `HEAP_START` address defined above. Of course it page-faults: We have forgotten to map the heap memory to some physical memory. [page fault]: http://wiki.osdev.org/Exceptions#Page_Fault @@ -428,7 +428,7 @@ extern crate once; The crate provides an [assert_has_not_been_called!] macro (sorry for the long name :D). We can use it to fix the safety problem easily: -[assert_has_not_been_called!]: https://phil-opp.rustdocs.org/once/macro.assert_has_not_been_called!.html +[assert_has_not_been_called!]: https://docs.rs/once/0.3.2/once/macro.assert_has_not_been_called!.html ``` rust // in src/memory/mod.rs diff --git a/blog/post/09-catching-exceptions.md b/blog/post/09-catching-exceptions.md index a074b0a7..64dfa5fa 100644 --- a/blog/post/09-catching-exceptions.md +++ b/blog/post/09-catching-exceptions.md @@ -412,7 +412,7 @@ extern "C" fn divide_by_zero_handler() -> ! { loop {} } ``` -We register a single handler function for a [divide by zero error] (index 0). Like the name says, this exception occurs when dividing a number by 0. Thus we have an easy way to test our new exception handler. +We register a single handler function for a [divide by zero error] \(index 0). Like the name says, this exception occurs when dividing a number by 0. Thus we have an easy way to test our new exception handler. [divide by zero error]: http://wiki.osdev.org/Exceptions#Divide-by-zero_Error diff --git a/blog/post/10-better-exception-messages.md b/blog/post/10-better-exception-messages.md index f26cc0a9..1d67121e 100644 --- a/blog/post/10-better-exception-messages.md +++ b/blog/post/10-better-exception-messages.md @@ -385,7 +385,7 @@ The base pointer is initialized directly from the stack pointer (`rsp`) after pu The reason is that our exception handler is defined as `extern "C" function`, which specifies that it's using the C [calling convention]. On x86_64 Linux, the C calling convention is specified by the System V AMD64 ABI ([PDF][system v abi]). Section 3.2.2 defines the following: [calling convention]: https://en.wikipedia.org/wiki/X86_calling_conventions -[system v abi]: http://www.x86-64.org/documentation/abi.pdf +[system v abi]: http://web.archive.org/web/20160801075139/http://www.x86-64.org/documentation/abi.pdf > The end of the input argument area shall be aligned on a 16 byte boundary. In other words, the value (%rsp + 8) is always a multiple of 16 when control is transferred to the function entry point.