Fix lot of dead links in both the 2nd and 1st edition

blog/content/first-edition/extra/naked-exceptions/01-catching-exceptions/index.md

@@ -377,7 +377,7 @@ We can't know when the next IDT will be loaded. Maybe never. So in the worst cas
 
 This is exactly the definition of a [static lifetime]. So we can easily ensure that the IDT lives long enough by adding a `'static` requirement to the signature of the `load` function:
 
-[static lifetime]: http://rustbyexample.com/scope/lifetime/static_lifetime.html
+[static lifetime]: https://doc.rust-lang.org/rust-by-example/scope/lifetime/static_lifetime.html
 
 ```rust
 pub fn load(&'static self) {...}
@@ -517,9 +517,9 @@ That's a not our exception handler. The reason is that Rust itself checks for a
 ### Inline Assembly
 In order to cause a divide-by-zero exception, we need to execute a [div] or [idiv] assembly instruction with operand 0. We could write a small assembly function and call it from our Rust code. An easier way is to use Rust's [inline assembly] macro.
 
-[div]: http://x86.renejeschke.de/html/file_module_x86_id_72.html
-[idiv]: http://x86.renejeschke.de/html/file_module_x86_id_137.html
-[inline assembly]: https://doc.rust-lang.org/book/inline-assembly.html
+[div]: https://www.felixcloutier.com/x86/div
+[idiv]: https://www.felixcloutier.com/x86/idiv
+[inline assembly]: https://doc.rust-lang.org/1.10.0/book/inline-assembly.html
 
 Inline assembly allows us to write raw x86 assembly within a Rust function. The feature is unstable, so we need to add `#![feature(asm)]` to our `src/lib.rs`. Then we're able to write a `divide_by_zero` function:
 

blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md

@@ -75,7 +75,7 @@ extern "C" fn divide_by_zero_handler() -> ! {
 ```
 We're using [inline assembly] here to load the value from the `rsp` register into `stack_frame`. The syntax is a bit strange, so here's a quick explanation:
 
-[inline assembly]: https://doc.rust-lang.org/nightly/book/inline-assembly.html
+[inline assembly]: https://doc.rust-lang.org/1.10.0/book/inline-assembly.html
 
 - The `asm!` macro emits raw assembly instructions. This is the only way to read raw register values in Rust.
 - We insert a single assembly instruction: `mov $0, rsp`. It moves the value of `rsp` to some register (the `$0` is a placeholder for an arbitrary register, which gets filled by the compiler).
@@ -339,7 +339,7 @@ objdump -d build/kernel-x86_64.bin | grep "10cf08:"
 ```
 The [movaps] instruction is an [SSE] instruction that moves aligned 128bit values. It can fail for a number of reasons:
 
-[movaps]: http://x86.renejeschke.de/html/file_module_x86_id_180.html
+[movaps]: https://www.felixcloutier.com/x86/movaps
 [SSE]: https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
 
 1. For an illegal memory operand effective address in the CS, DS, ES, FS or GS segments.
@@ -497,7 +497,7 @@ Invalid opcode faults have the vector number 6, so we set the 6th IDT entry. Thi
 
 We can test our new handler with the special [ud2] instruction, which generates a invalid opcode:
 
-[ud2]: http://x86.renejeschke.de/html/file_module_x86_id_318.html
+[ud2]: https://www.felixcloutier.com/x86/ud
 
 ```rust
 // in src/lib.rs

blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md

@@ -459,7 +459,7 @@ In order to fix this problem, we need to backup all caller-saved multimedia regi
 
 The Rust compiler (and LLVM) assume that the `x86_64-unknown-linux-gnu` target supports only MMX and SSE, so we don't need to save the `ymm0` through `ymm15`. But we need to save `xmm0` through `xmm15` and also `mm0` through `mm7`. There is a special instruction to do this: [fxsave]. This instruction saves the floating point and multimedia state to a given address. It needs _512 bytes_ to store that state.
 
-[fxsave]: http://x86.renejeschke.de/html/file_module_x86_id_128.html
+[fxsave]: https://www.felixcloutier.com/x86/fxsave
 
 In order to save/restore the multimedia registers, we _could_ add new macros:
 
@@ -482,7 +482,7 @@ macro_rules! restore_multimedia_registers {
 ```
 First, we reserve the 512 bytes on the stack and then we use `fxsave` to backup the multimedia registers. In order to restore them later, we use the [fxrstor] instruction. Note that `fxsave` and `fxrstor` require a 16 byte aligned memory address.
 
-[fxrstor]: http://x86.renejeschke.de/html/file_module_x86_id_127.html
+[fxrstor]: https://www.felixcloutier.com/x86/fxrstor
 
 However, _we won't do it that way_. The problem is the large amount of memory required. We will reuse the same code when we handle hardware interrupts in a future post. So for each mouse click, pressed key, or arrived network package we need to write 512 bytes to memory. This would be a huge performance problem.