CPU Exceptions

[utterances-bot]

This is a general purpose comment thread for the “CPU Exceptions” post.

[dodikk]

Got a compiler error while trying out the code from listing.

error: use of deprecated item 'x86_64::structures::idt::Idt': type was renamed to `InterruptDescriptorTable`, the old name will removed in the next major version
  --> src/main.rs:56:31
   |
56 | use x86_64::structures::idt::{Idt, ExceptionStackFrame};
   |                               ^^^

The error is obvious to fix.
Still, it would be a better experience to have correct listings out of box.

P.S. My code has the x86_64 = "0.2.6" dependency as recommended in the previous articles.

A dedicated github issue : #452

[phil-opp]

Yeah, we released a new x86_64 version with this renaming a few days ago. I thought it's better to wait a bit before updating the post to avoid breakage for the users on older versions. Normally the deprecation only causes a warning instead of an error, so I thought this wouldn't break new users.

The question is why it's an error for you. Are you explicitly using deny(warnings) or something like that?

[dodikk]

The question is why it's an error for you. Are you explicitly using deny(warnings) or something like that?

Yes, that's the case. I've continued the discussion (a few more questions from me) in a dedicated ticket.

[yjhmelody]

I consider it strange to write these exception codes to main.rs or bin/*.rs. Why not write them to lib.rs which can pub a code.

[phil-opp]

Because we want to do different things on an exception (compare the implementations of the breakpoint_handler functions).

Edit: We moved the exception handlers to an interrupts module in #475.

[k0pernicus]

Thank you first for this awesome blog post!
There is an error in the part "Loading the IDT", where, just before the subpart "Lazy Statics to the Rescue", you are declaring your IDT variable as an Option<...>.
I think you have to remove the Option type here :)

Good luck, and thanks again!

[phil-opp]

@k0pernicus You're right, thank you! Fixed in 442da8c.

[lilyball]

Why does src/interrupts.rs have extern crate x86_64;? That's already done in src/lib.rs.

[phil-opp]

Good catch! Removed in d9f3b3d.

[JoshMcguigan]

Hello, and thanks for your work on this blog series! I've been learning a lot by working through it.

One thing I was unsure about in this section, is why does the integration test not rely on our new interrupts module? It seems the test is actually checking whether the x86_64 crate is correct. Am I missing something here?

[phil-opp]

@JoshMcguigan Good point! I think I already had the test for double faults in mind when writing this post. The double fault test makes sense because it checks that we have a correct GDT and TSS setup, but the test in this post requires no previous setup so it really tests only the x86_64 crate.

I don't think that we can reuse the interrupts module for the test, because we need to do different things in the handler functions. Therefore I propose to simply remove it. I opened #526 for this.

[AntoineSebert]

Is there a way to define your own interrupts with dedicated handlers (without colliding with the hardware interrupts to implement later) ?

[phil-opp]

@AntoineSebert You mean software interrupts? Yes, you can just use any of the higher IDT entries (i.e. the entries not used for exceptions or hardware interrupt).

[AntoineSebert]

@phil-opp
Since the OS is a x86-64 architecture and you use usize to access the elements, does it means that the theoretical maximal number of interrupts (and the IDT's max size) is 18.446.744.073.709.551.615 ?
So I can just assign a number higher than 47 (the last hardware interrupt's number) to an new interrupt ?

[phil-opp]

@AntoineSebert No, the Idt size is limited to 256 entries because the int instruction uses an u8 for the interrupt number. Accessing Idt[256] or higher will result in a panic, similar to index operations on arrays.

So I can just assign a number higher than 47 (the last hardware interrupt's number) to an new interrupt ?

Yes. For example, you could set Idt[60] to a handler function and then invoke int 60 to run it.

[midwinter1993]

Hi @phil-opp, great post!

I have the same question about the claim all registers are preserved of the x86-interrupt convention as @AtsukiTak.

I tested a code snippet:

extern "x86-interrupt" fn timer_handler(stack_frame: &mut InterruptStackFrame) {
}

and I disassemble it:

; extern "x86-interrupt" fn timer_handler(stack_frame: &mut InterruptStackFrame) {
  20f3a0: 50                            pushq   %rax
  20f3a1: 50                            pushq   %rax
  20f3a2: fc                            cld
  20f3a3: 48 8d 44 24 10                leaq    16(%rsp), %rax
  20f3a8: 48 89 04 24                   movq    %rax, (%rsp)
; }
  20f3ac: 48 83 c4 08                   addq    $8, %rsp
  20f3b0: 58                            popq    %rax
  20f3b1: 48 cf                         iretq

I didn't see pushing the general registers; so, where does the magic happens?
Thank you :-P

[GuillaumeDIDIER]

@midwinter1993 LLVM did the magic expected of it. It only saved registers that are clobbered by your function (hence rax). All other register are left unchanged hence there’s no need of saving and restoring them.

[midwinter1993]

@GuillaumeDIDIER
Thank you for clarifying the claim "preserves all registers". :-P

[phil-opp]

@midwinter1993 I just pushed a3eeb1d to make this more clear in the post. Thanks for asking!

[LloydoChan]

Hi Phil,
Love the series! With this post, when I use cargo xrun the executable seems to crash when it hits the "x86_64::instructions::interrupts::int3();" line and reboots over and over and qemu seems stuck in a loop. It never reaches the "it did not crash" println statement.

I've checked your branch for this post and verified there's no difference in code, cargo.toml nor the json file.

I've also commented the int3() line out and sprinkled some printlns here and there to see if the "right" functions are exectuted in my interrupts.rs and lib.rs files, so the functions to load the IDT are being hit.

Any ideas?

[2dav]

i had exact same issue, in my case the cause was the system global `RUSTFLAGS=-C target-cpu=native' set, it seems this environment variable somehow have a higher priority than 'features' from "x86_64-blog_os.json" so '-sse,-mmx' have no effect and this results in the issue mentioned in the first post of the series.

[GuillaumeDIDIER]

Hi Phil,
Love the series! With this post, when I use cargo xrun the executable seems to crash when it hits the "x86_64::instructions::interrupts::int3();" line and reboots over and over and qemu seems stuck in a loop. It never reaches the "it did not crash" println statement.

I've checked your branch for this post and verified there's no difference in code, cargo.toml nor the json file.

I've also commented the int3() line out and sprinkled some printlns here and there to see if the "right" functions are exectuted in my interrupts.rs and lib.rs files, so the functions to load the IDT are being hit.

Any ideas?

The reboot looks like a triple fault (which is not surprising given that we don't have any double fault handler around).
I could suggest making use of an actual debugger (bochs with internal debugger is what I've been using), which could allow you to pin point what was the last instruction executed before things blew up (I now there are a few issues with stack alignment that have caused issue in the past if sse support is enabled)

[phil-opp]

Hi @RoidoChan, great to hear that you like the blog!

I've checked your branch for this post and verified there's no difference in code, cargo.toml nor the json file.

Have you tried cloning the repo and running it directly? Sometimes it's a small typo or a file that one didn't think of that is causing the issue. Also, if you have your code online somewhere I can take a look and try to reproduce it.

With this post, when I use cargo xrun the executable seems to crash when it hits the "x86_64::instructions::interrupts::int3();" line and reboots over and over and qemu seems stuck in a loop.

Sounds like something is wrong with your IDT setup. You can try passing -d int to QEMU (through cargo xrun -- -d int) to get a list of exceptions that occur. This trace contains the value of the instruction pointer for each exception, which you can then use to find out which instruction is causing it. A simple way for that is to grep the disassembly of your kernel (e.g. obtained via objdump -d path_to_your_kernel_bin).

Hope this helps! Please let me know what the issue was when you find it.

[LloydoChan]

Hi @GuillaumeDIDIER
Thanks for replying!

Hi @phil-opp,
I had a real nightmare trying to get cargo objdump -d to work, as It seemed the objdump didn't recognize the x86_64-unknown-none target for some reason, even i explicitly stated the .json file for the target.

I moved some "use" statements around in the .rs files and it started to work for some reason? Worst thing is I didn't do a commit of the buggy version, so I can't diff and see exactly was causing the issue. Sorry!

Thanks so much for your time, and again the blog is great. Learning some comp sci fundamentals I never really understood, despite working professionally in games for some years.

signed up as a Patron! Keep it going!

[phil-opp]

@RoidoChan

I had a real nightmare trying to get cargo objdump -d to work, as It seemed the objdump didn't recognize the x86_64-unknown-none target for some reason, even i explicitly stated the .json file for the target.

Yeah, I found cargo objdump difficult to use too. If you're on Linux or macOS, I recommend just using the system objdump on the ELF executable.

I moved some "use" statements around in the .rs files and it started to work for some reason? Worst thing is I didn't do a commit of the buggy version, so I can't diff and see exactly was causing the issue. Sorry!

No worries, great to hear that it's working now!

Thanks so much for your time, and again the blog is great. Learning some comp sci fundamentals I never really understood, despite working professionally in games for some years.

signed up as a Patron! Keep it going!

It makes me happy to hear that. Thanks a lot for supporting me!

[JulesGuillou]

Hi @phil-opp, first things first, a lot of thanks for your posts!

I'm getting an issue with the x86-interrupt:

error[E0658]: x86-interrupt ABI is experimental and subject to change
  --> src\interrupts.rs:17:8
   |
17 | extern "x86-interrupt" fn breakpoint_handler(stack_frame: InterruptStackFrame) {
   |        ^^^^^^^^^^^^^^^
   |
   = note: see issue #40180 <https://github.com/rust-lang/rust/issues/40180> for more information
   = help: add `#![feature(abi_x86_interrupt)]` to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `rust_kernel`

To learn more, run the command again with --verbose.

But I do have the #![feature(abi_x86_interrupt)] on top of my lib.rs file.
Did I miss anything?
Thanks for the reply :)

[k0pernicus]

Hi,
Is it possible to know which rust compiler version you are using please? :)

From what I see the tracking issue for the x86-interrupt calling convention is still open (rust-lang/rust#40180), but the support inside rustc has been merged since more than 3 years now (rust-lang/rust#39832).

Thanks!

[JulesGuillou]

Hey, my rust compiler is the following:
rustc 1.55.0-nightly (885399992 2021-07-06)

[k0pernicus]

Thanks, I supposed at the beginning you were using an old stable version to be honest...

If you added #![feature(abi_x86_interrupt)] to the crate attributes it should work actually 🤔
I am as confused as you now - sorry :/

[JulesGuillou]

The errore is likely on my side, just tested with his git content and it seems to work

[phil-opp]

Hi @JulesGuillou, were you able to fix your issue yet? It's difficult to find the issue without seeing the code, but my guess is that you accidentally defined the mod interrupts in both your lib.rs and main.rs (instead of only in your lib.rs). This way, the interrupts.rs file would be compiled twice, once with the #![feature(abi_x86_interrupt)] (when building your lib.rs) and once without it (when building your main.rs). If this is the case, you should be able to fix the issue by removing the mod interrupts statement from your main.rs.

[DIngDONG230]

Is this only for computers with x86_64 cpu type. If yes how can we make it for both amd and intel

[bjorn3]

Yes, this is only for x86_64 cpus. It works with both intel and amd cpus as blog os doesn't use any vendor specific x86_64 extensions.

[DIngDONG230]

what about arm cpu's?

[bjorn3]

Blog os doesn't support arm cpu's. While most of the basic concepts are similar, you need different code to target x86_64 and arm as the details differ sufficiently.

[MCorange99]

still a great blog/tutorial even after 4 years!

[kennystrawnmusic]

Question for the core team: If you already have a handler for a fault that's leading to a double fault, then why would the double fault handler still get invoked instead of one of the precursor fault handlers?

I'm now having an issue where two page faults are leading to a double fault despite the fact that I already have a page fault handler — something that shouldn't be happening. Update: using a huge page for the ABAR got rid of the page fault that led to the double fault, but this still begs the question of why a page fault would still lead to a double fault despite the existence of a page fault handler regardless. Page overflow, perhaps?

[kennystrawnmusic]

Alright, even exhaustively indexing all double fault precursor handlers at the beginning of the TSS still didn't get rid of the double fault — why?

[kennystrawnmusic]

Oops, forgot to add the stack indices to the TSS itself — that might explain it.

[kennystrawnmusic]

Aha! NOW the page fault handler is being invoked properly, as it should be.

[kennystrawnmusic]

So the problem seems to be that something in the code to the AHCI driver is overflowing the stack — the question, of course, is what. @IsaacWoods — any idea?

[kennystrawnmusic]

Although some fairly large arrays of bytes need to be defined as e.g. data buffers, they shouldn't be overflowing an 80+ megabyte kernel stack. You'd need 800 of those 100KB arrays. Recursion is the only thing that could possibly overrun a stack that big, and recursion is definitely something I'm not seeing there — unless I'm missing something.

Edit: Tried commenting out the * 512 in the buffer sizes to test this, and it made no difference. So what else could it be?

[EliasEly]

I am surprised that the interrupt test shows a virtual address in the console. So far no paging has been enabled so how can we have a virtual address? Is it because the function which does the printing assumes the paging is enabled and thus has a default printing?

[bjorn3]

The bootloader crate sets up a default page mapping.

[hatchardm]

Hi Phil,
I am getting the following compile error:
error[E0308]: mismatched types
--> kernel/src/interrupts.rs:6:35
|
6 | idt.breakpoint.set_handler_fn(breakpoint_handler);
| -------------- ^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item
| |
| arguments to this method are incorrect
|
= note: expected fn pointer extern "x86-interrupt" fn(InterruptStackFrame)
found fn item extern "x86-interrupt" for<'a> fn(&'a mut InterruptStackFrame) {breakpoint_handler}
note: method defined here
--> /home/mark/.cargo/registry/src/index.crates.io-6f17d22bba15001f/x86_64-0.14.12/src/structures/idt.rs:795:12
|
795 | pub fn set_handler_fn(&mut self, handler: F) -> &mut EntryOptions {
| ^^^^^^^^^^^^^^
This is the section before Loading the IDT in the blog.

[bjorn3]

Looks like your handler needs to stop taking the InterruptStackFrame argument as mutable reference and instead directly pass it by-value.

[hatchardm]

Thankyou for your help