diff --git a/blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md b/blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md index 6c941a43..30dba545 100644 --- a/blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md +++ b/blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md @@ -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. diff --git a/blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md b/blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md index 8bdf8566..69c41046 100644 --- a/blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md +++ b/blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md @@ -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 diff --git a/blog/content/first-edition/posts/04-printing-to-screen/index.md b/blog/content/first-edition/posts/04-printing-to-screen/index.md index 94b83a2e..77d657a2 100644 --- a/blog/content/first-edition/posts/04-printing-to-screen/index.md +++ b/blog/content/first-edition/posts/04-printing-to-screen/index.md @@ -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` 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)] diff --git a/blog/content/first-edition/posts/09-handling-exceptions/index.md b/blog/content/first-edition/posts/09-handling-exceptions/index.md index f22447ad..c64f6ca3 100644 --- a/blog/content/first-edition/posts/09-handling-exceptions/index.md +++ b/blog/content/first-edition/posts/09-handling-exceptions/index.md @@ -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 diff --git a/blog/content/first-edition/posts/10-double-faults/index.md b/blog/content/first-edition/posts/10-double-faults/index.md index 946b9579..c5c2f6ee 100644 --- a/blog/content/first-edition/posts/10-double-faults/index.md +++ b/blog/content/first-edition/posts/10-double-faults/index.md @@ -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. diff --git a/blog/content/second-edition/posts/09-paging-implementation/index.md b/blog/content/second-edition/posts/09-paging-implementation/index.md index 3e5c1965..7dc03506 100644 --- a/blog/content/second-edition/posts/09-paging-implementation/index.md +++ b/blog/content/second-edition/posts/09-paging-implementation/index.md @@ -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` diff --git a/blog/content/second-edition/posts/10-heap-allocation/index.md b/blog/content/second-edition/posts/10-heap-allocation/index.md index ee3db14e..3254121d 100644 --- a/blog/content/second-edition/posts/10-heap-allocation/index.md +++ b/blog/content/second-edition/posts/10-heap-allocation/index.md @@ -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 diff --git a/blog/templates/first-edition/comments/printing-to-screen.html b/blog/templates/first-edition/comments/printing-to-screen.html index 44316f07..8a4e521d 100644 --- a/blog/templates/first-edition/comments/printing-to-screen.html +++ b/blog/templates/first-edition/comments/printing-to-screen.html @@ -227,7 +227,7 @@ - Antworten
Chris Latham•

hey, great articles so far!

i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.

if i add that code in, i get these linker errors:

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'

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?

thanks in advance.

0 + Antworten
Chris Latham•

hey, great articles so far!

i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.

if i add that code in, i get these linker errors:

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'

core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'

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?

thanks in advance.

0