mirror of
https://github.com/phil-opp/blog_os.git
synced 2025-12-16 22:37:49 +00:00
Fix remaining dead links
This commit is contained in:
@@ -84,7 +84,7 @@ We're using [inline assembly] here to load the value from the `rsp` register int
|
||||
- After the third colon, the macro expects so called [clobbers]. We don't change any register values, so we leave it empty too.
|
||||
- The last block (after the 4th colon) specifies options. The `intel` option tells the compiler that our code is in Intel assembly syntax (instead of the default AT&T syntax).
|
||||
|
||||
[clobbers]: https://doc.rust-lang.org/nightly/book/inline-assembly.html#clobbers
|
||||
[clobbers]: https://doc.rust-lang.org/1.10.0/book/inline-assembly.html#clobbers
|
||||
|
||||
So the inline assembly loads the stack pointer value to `stack_frame` at the very beginning of our function. Thus we have a pointer to the exception stack frame and are able to pretty-print its `Debug` formatting through the `{:#?}` argument.
|
||||
|
||||
|
||||
@@ -250,7 +250,7 @@ However, there is a major difference between exceptions and function calls: A fu
|
||||
[Calling conventions] specify the details of a function call. For example, they specify where function parameters are placed (e.g. in registers or on the stack) and how results are returned. On x86_64 Linux, the following rules apply for C functions (specified in the [System V ABI]):
|
||||
|
||||
[Calling conventions]: https://en.wikipedia.org/wiki/Calling_convention
|
||||
[System V ABI]: http://refspecs.linuxbase.org/elf/x86-64-abi-0.99.pdf
|
||||
[System V ABI]: http://refspecs.linuxbase.org/elf/gabi41.pdf
|
||||
|
||||
- the first six integer arguments are passed in registers `rdi`, `rsi`, `rdx`, `rcx`, `r8`, `r9`
|
||||
- additional arguments are passed on the stack
|
||||
|
||||
@@ -89,7 +89,7 @@ pub enum Color {
|
||||
```
|
||||
We use a [C-like enum] here to explicitly specify the number for each color. Because of the `repr(u8)` attribute each enum variant is stored as an `u8`. Actually 4 bits would be sufficient, but Rust doesn't have an `u4` type.
|
||||
|
||||
[C-like enum]: http://rustbyexample.com/custom_types/enum/c_like.html
|
||||
[C-like enum]: https://doc.rust-lang.org/rust-by-example/custom_types/enum/c_like.html
|
||||
|
||||
Normally the compiler would issue a warning for each unused variant. By using the `#[allow(dead_code)]` attribute we disable these warnings for the `Color` enum.
|
||||
|
||||
@@ -142,7 +142,7 @@ pub struct Writer {
|
||||
```
|
||||
The writer will always write to the last line and shift lines up when a line is full (or on `\n`). The `column_position` field keeps track of the current position in the last row. The current foreground and background colors are specified by `color_code` and a pointer to the VGA buffer is stored in `buffer`. To make it possible to create a `static` Writer later, the `buffer` field stores an `Unique<Buffer>` instead of a plain `*mut Buffer`. [Unique] is a wrapper that implements Send/Sync and is thus usable as a `static`. Since it's unstable, you may need to add the `unique` feature to `lib.rs`:
|
||||
|
||||
[Unique]: https://doc.rust-lang.org/nightly/core/ptr/struct.Unique.html
|
||||
[Unique]: https://doc.rust-lang.org/1.10.0/core/ptr/struct.Unique.html
|
||||
|
||||
```rust
|
||||
// in src/lib.rs
|
||||
@@ -210,7 +210,7 @@ The reason it that Rust _moves_ values by default instead of copying them like o
|
||||
To fix it, we can implement the [Copy] trait for the `ColorCode` type. The easiest way to do this is to use the built-in [derive macro]:
|
||||
|
||||
[Copy]: https://doc.rust-lang.org/nightly/core/marker/trait.Copy.html
|
||||
[derive macro]: http://rustbyexample.com/trait/derive.html
|
||||
[derive macro]: https://doc.rust-lang.org/rust-by-example/custom_types/enum/c_like.html
|
||||
|
||||
```rust
|
||||
#[derive(Debug, Clone, Copy)]
|
||||
|
||||
@@ -274,7 +274,7 @@ This error occurs because the `x86-interrupt` calling convention is still unstab
|
||||
### Loading the IDT
|
||||
In order that the CPU uses our new interrupt descriptor table, we need to load it using the [`lidt`] instruction. The `Idt` struct of the `x86_64` provides a [`load`][Idt::load] method function for that. Let's try to use it:
|
||||
|
||||
[`lidt`]: http://x86.renejeschke.de/html/file_module_x86_id_156.html
|
||||
[`lidt`]: https://www.felixcloutier.com/x86/lgdt:lidt
|
||||
[Idt::load]: https://docs.rs/x86_64/0.1.1/x86_64/structures/idt/struct.Idt.html#method.load
|
||||
|
||||
```rust
|
||||
|
||||
@@ -136,7 +136,7 @@ First Exception | Second Exception
|
||||
[Page Fault]: http://wiki.osdev.org/Exceptions#Page_Fault
|
||||
|
||||
|
||||
[AMD64 manual]: http://developer.amd.com/wordpress/media/2012/10/24593_APM_v21.pdf
|
||||
[AMD64 manual]: https://www.amd.com/system/files/TechDocs/24593.pdf
|
||||
|
||||
So for example a divide-by-zero fault followed by a page fault is fine (the page fault handler is invoked), but a divide-by-zero fault followed by a general-protection fault leads to a double fault.
|
||||
|
||||
@@ -357,7 +357,7 @@ impl MemoryController {
|
||||
The `MemoryController` struct holds the three types that are required for `alloc_stack` and provides a simpler interface (only one argument). The `alloc_stack` wrapper just takes the tree types as `&mut` through [destructuring] and forwards them to the `stack_allocator`. The [ref mut]-s are needed to take the inner fields by mutable reference. Note that we're re-exporting the `Stack` type since it is returned by `alloc_stack`.
|
||||
|
||||
[destructuring]: https://doc.rust-lang.org/1.10.0/book/patterns.html#destructuring
|
||||
[ref mut]: http://rust-lang.github.io/book/ch18-00-patterns.html#ref-and-ref-mut
|
||||
[ref mut]: https://doc.rust-lang.org/1.30.0/book/second-edition/ch18-03-pattern-syntax.html#creating-references-in-patterns-with-ref-and-ref-mut
|
||||
|
||||
The last step is to create a `StackAllocator` and return a `MemoryController` from `memory::init`:
|
||||
|
||||
@@ -496,7 +496,7 @@ We define that the 0th IST entry is the double fault stack (any other IST index
|
||||
Now that we created a new TSS, we need a way to tell the CPU that it should use it. Unfortunately, this is a bit cumbersome, since the TSS is a Task State _Segment_ (for historical reasons). So instead of loading the table directly, we need to add a new segment descriptor to the [Global Descriptor Table] \(GDT). Then we can load our TSS invoking the [`ltr` instruction] with the respective GDT index.
|
||||
|
||||
[Global Descriptor Table]: http://www.flingos.co.uk/docs/reference/Global-Descriptor-Table/
|
||||
[`ltr` instruction]: http://x86.renejeschke.de/html/file_module_x86_id_163.html
|
||||
[`ltr` instruction]: https://www.felixcloutier.com/x86/ltr
|
||||
|
||||
### The Global Descriptor Table (again)
|
||||
The Global Descriptor Table (GDT) is a relict that was used for [memory segmentation] before paging became the de facto standard. It is still needed in 64-bit mode for various things such as kernel/user mode configuration or TSS loading.
|
||||
|
||||
@@ -670,7 +670,7 @@ We can't directly return a `MappedPageTable` from the function because it is gen
|
||||
|
||||
The [`MappedPageTable::new`] function expects two parameters: a mutable reference to the level 4 page table and a `phys_to_virt` closure that converts a physical frame to a page table pointer `*mut PageTable`. For the first parameter we can reuse our `active_level_4_table` function. For the second parameter, we create a closure that uses the `physical_memory_offset` to perform the conversion.
|
||||
|
||||
[`MappedPageTable::new`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/struct.MappedPageTable.html#method.new
|
||||
[`MappedPageTable::new`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MappedPageTable.html#method.new
|
||||
|
||||
We also make the `active_level_4_table` private because it should only be called from the `init` function from now on.
|
||||
|
||||
@@ -760,7 +760,7 @@ The `map_to` function can fail, so it returns a [`Result`]. Since this is just s
|
||||
[`Result`]: https://doc.rust-lang.org/core/result/enum.Result.html
|
||||
[`expect`]: https://doc.rust-lang.org/core/result/enum.Result.html#method.expect
|
||||
[`MapperFlush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MapperFlush.html
|
||||
[`flush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/struct.MapperFlush.html#method.flush
|
||||
[`flush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MapperFlush.html#method.flush
|
||||
[must_use]: https://doc.rust-lang.org/std/result/#results-must-be-used
|
||||
|
||||
#### A dummy `FrameAllocator`
|
||||
|
||||
@@ -626,7 +626,7 @@ Of course there are many more allocation and collection types in the `alloc` cra
|
||||
- [`BTreeMap`] and [`BTreeSet`]
|
||||
|
||||
[`Arc`]: https://doc.rust-lang.org/alloc/sync/struct.Arc.html
|
||||
[`String`]: https://doc.rust-lang.org/alloc/collections/string/struct.String.html
|
||||
[`String`]: https://doc.rust-lang.org/alloc/string/struct.String.html
|
||||
[`format!`]: https://doc.rust-lang.org/alloc/macro.format.html
|
||||
[`LinkedList`]: https://doc.rust-lang.org/alloc/collections/linked_list/struct.LinkedList.html
|
||||
[`VecDeque`]: https://doc.rust-lang.org/alloc/collections/vec_deque/struct.VecDeque.html
|
||||
|
||||
@@ -227,7 +227,7 @@
|
||||
</path>
|
||||
</g>
|
||||
</svg>
|
||||
</a><a rel="nofollow" href="#" class="reply">Antworten</a></div><div class="isso-follow-up"></div></div></div></div></div></div><div id="isso-20" class="isso-comment isso-no-votes"><div class="avatar"><svg version="1.1" viewBox="0 0 48 48" preserveAspectRatio="xMinYMin meet" shape-rendering="crispEdges" data-hash="1d800ad10773"><rect x="0" y="0" width="56" height="56" style="fill: #f0f0f0"></rect><rect x="4" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="36" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="28" width="8" height="8" style="fill: #9163b6"></rect></svg></div><div class="text-wrapper"><div role="meta" class="isso-comment-header"><span class="author">Chris Latham</span><span class="spacer">•</span><a rel="nofollow" href="#isso-20" class="permalink"><time title="Wed Jun 22 2016 16:02:16 GMT+0200 (Central European Summer Time)" datetime="2016-05-03T14:02:16Z">vor 3 Jahren</time></a><span class="note"></span></div><div class="text"><p>hey, great articles so far!</p><p>i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.</p><p>if i add that code in, i get these linker errors:</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'</p><p><a rel="nofollow" href="http://core.0.rs">core.0.rs</a>:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'</p><p><a rel="nofollow" href="http://core.0.rs">core.0.rs</a>:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'</p><p>i've gone back and checked that i set panic to "abort" for both dev and release profiles in my config.toml, the same way you did to fix the unwinding issues. everything seems to match up with what you have. what have i missed?</p><p>thanks in advance.</p></div><div class="isso-comment-footer"><span class="votes">0</span><a rel="nofollow" href="#" class="upvote"><!-- Generator: IcoMoon.io --><svg width="16" height="16" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="gray">
|
||||
</a><a rel="nofollow" href="#" class="reply">Antworten</a></div><div class="isso-follow-up"></div></div></div></div></div></div><div id="isso-20" class="isso-comment isso-no-votes"><div class="avatar"><svg version="1.1" viewBox="0 0 48 48" preserveAspectRatio="xMinYMin meet" shape-rendering="crispEdges" data-hash="1d800ad10773"><rect x="0" y="0" width="56" height="56" style="fill: #f0f0f0"></rect><rect x="4" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="36" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="28" width="8" height="8" style="fill: #9163b6"></rect></svg></div><div class="text-wrapper"><div role="meta" class="isso-comment-header"><span class="author">Chris Latham</span><span class="spacer">•</span><a rel="nofollow" href="#isso-20" class="permalink"><time title="Wed Jun 22 2016 16:02:16 GMT+0200 (Central European Summer Time)" datetime="2016-05-03T14:02:16Z">vor 3 Jahren</time></a><span class="note"></span></div><div class="text"><p>hey, great articles so far!</p><p>i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.</p><p>if i add that code in, i get these linker errors:</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'</p><p>i've gone back and checked that i set panic to "abort" for both dev and release profiles in my config.toml, the same way you did to fix the unwinding issues. everything seems to match up with what you have. what have i missed?</p><p>thanks in advance.</p></div><div class="isso-comment-footer"><span class="votes">0</span><a rel="nofollow" href="#" class="upvote"><!-- Generator: IcoMoon.io --><svg width="16" height="16" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="gray">
|
||||
<g>
|
||||
<path d="M 24.773,18.299c-0.651-0.669-7.512-7.203-7.512-7.203C 16.912,10.739, 16.456,10.56, 16,10.56c-0.458,0-0.914,0.179-1.261,0.536 c0,0-6.861,6.534-7.514,7.203c-0.651,0.669-0.696,1.872,0,2.586c 0.698,0.712, 1.669,0.77, 2.522,0L 16,14.89l 6.251,5.995 c 0.854,0.77, 1.827,0.712, 2.522,0C 25.47,20.17, 25.427,18.966, 24.773,18.299z">
|
||||
</path>
|
||||
|
||||
Reference in New Issue
Block a user