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

Fix broken links

Browse Source
This commit is contained in:
Philipp Oppermann
2017-01-04 16:36:25 +01:00
parent ae1c9b3739
commit a8847c22ef
5 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
blog/post/04-printing-to-screen.md
View File

@@ -486,7 +486,7 @@ pub static WRITER: Mutex<Writer> = 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

2
blog/post/07-remap-the-kernel.md
View File

@@ -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

4
blog/post/08-kernel-heap.md
View File

@@ -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

2
blog/post/09-catching-exceptions.md
View File

@@ -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

2
blog/post/10-better-exception-messages.md
View File

@@ -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.