From c76516db7575d860d7016f661cd067f335ddab17 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Sun, 29 Sep 2019 15:44:44 +0200 Subject: [PATCH] Fix anchor names of internal links --- blog/content/first-edition/posts/02-entering-longmode/index.md | 2 +- .../second-edition/posts/02-minimal-rust-kernel/index.md | 2 +- blog/content/second-edition/posts/06-double-faults/index.md | 2 +- .../second-edition/posts/08-paging-introduction/index.md | 2 +- .../second-edition/posts/09-paging-implementation/index.md | 2 +- blog/content/second-edition/posts/10-heap-allocation/index.md | 2 +- .../second-edition/posts/deprecated/10-advanced-paging/index.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/blog/content/first-edition/posts/02-entering-longmode/index.md b/blog/content/first-edition/posts/02-entering-longmode/index.md index 6a03ab55..cf5475fc 100644 --- a/blog/content/first-edition/posts/02-entering-longmode/index.md +++ b/blog/content/first-edition/posts/02-entering-longmode/index.md @@ -492,7 +492,7 @@ _Congratulations_! You have successfully wrestled through this CPU configuration #### One Last Thing Above, we reloaded the code segment register `cs` with the new GDT offset. However, the data segment registers `ss`, `ds`, `es`, `fs`, and `gs` still contain the data segment offsets of the old GDT. This isn't necessarily bad, since they're ignored by almost all instructions in 64-bit mode. However, there are a few instructions that expect a valid data segment descriptor _or the null descriptor_ in those registers. An example is the the [iretq] instruction that we'll need in the [_Returning from Exceptions_] post. -[iretq]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md#the +[iretq]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md#the-iretq-instruction [_Returning from Exceptions_]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md To avoid future problems, we reload all data segment registers with null: diff --git a/blog/content/second-edition/posts/02-minimal-rust-kernel/index.md b/blog/content/second-edition/posts/02-minimal-rust-kernel/index.md index f9a29263..d95c5d74 100644 --- a/blog/content/second-edition/posts/02-minimal-rust-kernel/index.md +++ b/blog/content/second-edition/posts/02-minimal-rust-kernel/index.md @@ -275,7 +275,7 @@ Now we can rerun the above command with `xbuild` instead of `build`: We see that `cargo xbuild` cross-compiles the `core`, `compiler_builtin`, and `alloc` libraries for our new custom target. Since these libraries use a lot of unstable features internally, this only works with a [nightly Rust compiler]. Afterwards, `cargo xbuild` successfully compiles our `blog_os` crate. -[nightly Rust compiler]: @/second-edition/posts/01-freestanding-rust-binary/index.md#installing-rust-nightly +[nightly Rust compiler]: #installing-rust-nightly Now we are able to build our kernel for a bare metal target. However, our `_start` entry point, which will be called by the boot loader, is still empty. So let's output something to screen from it. diff --git a/blog/content/second-edition/posts/06-double-faults/index.md b/blog/content/second-edition/posts/06-double-faults/index.md index 233a368c..f7066e14 100644 --- a/blog/content/second-edition/posts/06-double-faults/index.md +++ b/blog/content/second-edition/posts/06-double-faults/index.md @@ -438,7 +438,7 @@ name = "stack_overflow" harness = false ``` -[without a test harness]: @/second-edition/posts/04-testing/index.md#no-harness +[without a test harness]: @/second-edition/posts/04-testing/index.md#no-harness-tests Now `cargo xtest --test stack_overflow` should compile successfully. The test fails of course, since the `unimplemented` macro panics. diff --git a/blog/content/second-edition/posts/08-paging-introduction/index.md b/blog/content/second-edition/posts/08-paging-introduction/index.md index 1ec1f01c..aa2ad0d2 100644 --- a/blog/content/second-edition/posts/08-paging-introduction/index.md +++ b/blog/content/second-edition/posts/08-paging-introduction/index.md @@ -296,7 +296,7 @@ The [`CR2`] register is automatically set by the CPU on a page fault and contain [`Cr2::read`]: https://docs.rs/x86_64/0.7.5/x86_64/registers/control/struct.Cr2.html#method.read [`PageFaultErrorCode`]: https://docs.rs/x86_64/0.7.5/x86_64/structures/idt/struct.PageFaultErrorCode.html [LLVM bug]: https://github.com/rust-lang/rust/issues/57270 -[`hlt_loop`]: @/second-edition/posts/07-hardware-interrupts/index.md#the +[`hlt_loop`]: @/second-edition/posts/07-hardware-interrupts/index.md#the-hlt-instruction Now we can try to access some memory outside our kernel: 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 f52491d0..56564d72 100644 --- a/blog/content/second-edition/posts/09-paging-implementation/index.md +++ b/blog/content/second-edition/posts/09-paging-implementation/index.md @@ -192,7 +192,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension]. -[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86 +[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86-64 We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits. 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 3e35619b..c1d34b19 100644 --- a/blog/content/second-edition/posts/10-heap-allocation/index.md +++ b/blog/content/second-edition/posts/10-heap-allocation/index.md @@ -392,7 +392,7 @@ We set the heap size to 100 KiB for now. If we need more space in the future, we If we tried to use this heap region now, a page fault would occur since the virtual memory region is not mapped to physical memory yet. To resolve this, we create an `init_heap` function that maps the heap pages using the [`Mapper` API] that we introduced in the [_"Paging Implementation"_] post: -[`Mapper` API]: @/second-edition/posts/09-paging-implementation/index.md#using-mappedpagetable +[`Mapper` API]: @/second-edition/posts/09-paging-implementation/index.md#using-offsetpagetable [_"Paging Implementation"_]: @/second-edition/posts/09-paging-implementation/index.md ```rust diff --git a/blog/content/second-edition/posts/deprecated/10-advanced-paging/index.md b/blog/content/second-edition/posts/deprecated/10-advanced-paging/index.md index d61f6237..9ff16ef8 100644 --- a/blog/content/second-edition/posts/deprecated/10-advanced-paging/index.md +++ b/blog/content/second-edition/posts/deprecated/10-advanced-paging/index.md @@ -156,7 +156,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension]. -[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86 +[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86-64 We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits.