Comments for "https://os.phil-opp.com/minimal-rust-kernel/"

[utterances-bot]

This is a general purpose comment thread for the “A Minimal Rust Kernel” post.

[neanias]

I updated my version of Rust nightly and now it compiles. Maybe it was just a version thing 🤷‍♂️

[Rabrg]

Running cargo xbuild --target x86_64-rot.json is producing the following error:

   Compiling rot v0.1.0 (file:///home/ryan/IdeaProjects/rot)
error: linker `lld` not found                                            ] 0/1: rot                                                                                        
  |
  = note: No such file or directory (os error 2)

error: aborting due to previous error

error: Could not compile `rot`.                                                                                                                                            

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

I'm using the latest version of rustc: rustc 1.29.0-nightly (9fd3d7899 2018-07-07)

[martica]

@Rabrg Rust just renamed the included linker to rust-lld. You'll need to add:

"linker": "rust-lld",

to your target .json file.

[Rabrg]

@martica That fixed it, thank you very much.

[phil-opp]

@Rabrg @martica Thanks for reporting, fixed in https://github.com/phil-opp/blog_os/pull/457.

[jweather]

I'd like to try this, but I can't get past the cargo install cargo-xbuild step -- it hangs on Compiling rustc-serialize v0.3.24.

[phil-opp]

Are you sure that it hangs? Some crates take a lot of time to compile...

[jweather]

Huh... it was hung for an hour earlier, but I just tried it again after a reboot and it completed in 5 minutes. Not sure what that was about...

[bashawhm]

I've been having an issue compiling, when I run bootimage build I get the following error:

Building kernel Compiling dagger_os v0.1.0 (file:///Users/hunter/projects/dagger_os) error: linking with rust-lld failed: signal: 6 | = note: "rust-lld" "-flavor" "gnu" "-L" "/Users/hunter/projects/dagger_os/target/sysroot/lib/rustlib/x86_64-dagger_os/lib" "/Users/hunter/projects/dagger_os/target/x86_64-dagger_os/debug/deps/dagger_os-f6bb7fe237e1ef8c.51lo5b25xax9v4cf.rcgu.o" "-o" "/Users/hunter/projects/dagger_os/target/x86_64-dagger_os/debug/deps/dagger_os-f6bb7fe237e1ef8c" "--gc-sections" "-L" "/Users/hunter/projects/dagger_os/target/x86_64-dagger_os/debug/deps" "-L" "/Users/hunter/projects/dagger_os/target/debug/deps" "-L" "/Users/hunter/projects/dagger_os/target/sysroot/lib/rustlib/x86_64-dagger_os/lib" "-Bstatic" "/Users/hunter/projects/dagger_os/target/x86_64-dagger_os/debug/deps/libbootloader_precompiled-859885908ea6b945.rlib" "/Users/hunter/projects/dagger_os/target/x86_64-dagger_os/debug/deps/libos_bootinfo-01e4331dd91811cf.rlib" "/Users/hunter/projects/dagger_os/target/sysroot/lib/rustlib/x86_64-dagger_os/lib/libcore-fa7df5887feea462.rlib" "/Users/hunter/projects/dagger_os/target/sysroot/lib/rustlib/x86_64-dagger_os/lib/libcompiler_builtins-dd491bf5751f5384.rlib" "-Bdynamic" = note: dyld: Library not loaded: @rpath/libLLVM.dylib Referenced from: /Users/hunter/projects/dagger_os/target/sysroot/lib/rustlib/x86_64-apple-darwin/bin/rust-lld Reason: image not found

error: aborting due to previous error

error: Could not compile dagger_os.

For reference I'm running MacOS 10.13.6 with cargo 1.29.0-nightly and bootimage 0.5.6. I also tried to grab whats on GitHub for blog_os and it failed with the same issue, any ideas?

[robert-w-gries]

@bashawhm Looks like the 8/30 nightly broke rust-lld for Mac and Linux. The Linux issue was fixed in 8/31, but it doesn't look like the Mac issue has been fixed yet. See rust-lang/rust#53813

You'll have to temporarily go back to the 8/29 rust nightly if you want to compile:

rustup override set nightly-2018-08-29

[bashawhm]

That fixed my issue, thanks!

[zeayes]

mark

[robert-w-gries]

@bashawhm nightly-2018-09-07 fixes the issue

[CRogers]

I'm a big fan of the bootimage tool (and cargo-xbuild), these kind of tools are what makes development faster and easier for everyone to get involved. Especially us on OS X - when I last tried to follow a tutorial in rust for an OS I spent the whole time getting cross compilation to work.

[tyfkda]

@phil-opp , Thank you for such a nice article. But I need help to fix an error occurred in Cargo xbuild:

vagrant@ubuntu-xenial:/vagrant/my_blog_os$ cargo xbuild --target x86_64-blog_os.json --verbose
+ "rustc" "--print" "sysroot"
+ "rustc" "--print" "target-list"
+ RUSTFLAGS="--sysroot /vagrant/my_blog_os/target/sysroot"
+ "cargo" "build" "--target" "x86_64-blog_os.json" "--verbose"
   Compiling blog_os v0.1.0 (file:///vagrant/my_blog_os)
     Running `rustc --crate-name blog_os src/main.rs --crate-type bin --emit=dep-info,link -C panic=abort -C debuginfo=2 -C metadata=dcb2b3028f3657a5 -C extra-filename=-dcb2b3028f3657a5 --out-dir /vagrant/my_blog_os/target/x86_64-blog_os/debug/deps --target /vagrant/my_blog_os/x86_64-blog_os.json -C incremental=/vagrant/my_blog_os/target/x86_64-blog_os/debug/incremental -L dependency=/vagrant/my_blog_os/target/x86_64-blog_os/debug/deps -L dependency=/vagrant/my_blog_os/target/debug/deps --sysroot /vagrant/my_blog_os/target/sysroot`
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/vagrant/my_blog_os/target/sysroot/lib/rustlib/x86_64-blog_os/lib" "/vagrant/my_blog_os/target/x86_64-blog_os/debug/deps/blog_os-dcb2b3028f3657a5.4pm8y5jd2ldoedmb.rcgu.o" "-o" "/vagrant/my_blog_os/target/x86_64-blog_os/debug/deps/blog_os-dcb2b3028f3657a5" "--gc-sections" "-L" "/vagrant/my_blog_os/target/x86_64-blog_os/debug/deps" "-L" "/vagrant/my_blog_os/target/debug/deps" "-L" "/vagrant/my_blog_os/target/sysroot/lib/rustlib/x86_64-blog_os/lib" "-Bstatic" "/vagrant/my_blog_os/target/sysroot/lib/rustlib/x86_64-blog_os/lib/libcore-8136d0f8d6ce6f91.rlib" "/vagrant/my_blog_os/target/sysroot/lib/rustlib/x86_64-blog_os/lib/libcompiler_builtins-7a28623ae500f96b.rlib" "-Bdynamic"
  = note: rust-lld: error: cannot open output file /vagrant/my_blog_os/target/x86_64-blog_os/debug/deps/blog_os-dcb2b3028f3657a5: Invalid argument

error: aborting due to previous error

error: Could not compile `blog_os`.

Caused by:
  process didn't exit successfully: `rustc --crate-name blog_os src/main.rs --crate-type bin --emit=dep-info,link -C panic=abort -C debuginfo=2 -C metadata=dcb2b3028f3657a5 -C extra-filename=-dcb2b3028f3657a5 --out-dir /vagrant/my_blog_os/target/x86_64-blog_os/debug/deps --target /vagrant/my_blog_os/x86_64-blog_os.json -C incremental=/vagrant/my_blog_os/target/x86_64-blog_os/debug/incremental -L dependency=/vagrant/my_blog_os/target/x86_64-blog_os/debug/deps -L dependency=/vagrant/my_blog_os/target/debug/deps --sysroot /vagrant/my_blog_os/target/sysroot` (exit code: 1)

Here is my environment:

vagrant@ubuntu-xenial:/vagrant/my_blog_os$ uname -a
Linux ubuntu-xenial 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27 10:45:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
vagrant@ubuntu-xenial:/vagrant/my_blog_os$ rustup show
Default host: x86_64-unknown-linux-gnu

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.30.0-nightly (90d36fb59 2018-09-13)
vagrant@ubuntu-xenial:/vagrant/my_blog_os$ rustc --version
rustc 1.30.0-nightly (90d36fb59 2018-09-13)
vagrant@ubuntu-xenial:/vagrant/my_blog_os$ cargo --version
cargo 1.30.0-nightly (b917e3524 2018-09-09)

I would really appreciate if someone could help me.

[robert-w-gries]

@tyfkda Did you set the linker-flavor properly?

It should be:

"linker-flavor": "ld.lld",
"linker": "rust-lld",

And the compilation error suggests the linker-flavor is gnu:

error: linking with `rust-lld` failed: exit code: 1
  |
 = note: "rust-lld" "-flavor" "gnu"

[tyfkda]

@robert-w-gries thank you to point out the problem. It looks suspicious.

But I use same target file written in the paragraph "Putting it Together" https://os.phil-opp.com/minimal-rust-kernel/#putting-it-together.

To test linker-flavor is working, I changed it from ld.lld to ld, error message said:

  = note: lld is a generic driver.
          Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-lld (WebAssembly) instead

so it seems linker-flavor is not ignored.

[robert-w-gries]

Can you share your repo? I can take a look and see if I can reproduce

[tyfkda]

@robert-w-gries , thank you for helping me! I put my repository at: https://github.com/tyfkda/my_blog_os

I ran a command:

$ cargo xbuild --target x86_64-blog_os.json --verbose

[robert-w-gries]

I am able to build your repo using the same command and same nightly version. Maybe do a cargo clean and try again? Also, make sure to run cargo update and make sure cargo xbuild is up to date.

[tyfkda]

Hmm, I tried cargo clean or cargo update (or rustup update), but build failed at the same point, = note: "rust-lld" "-flavor" "gnu" .... Maybe I made some mistake in Rust environment setup.

Anyway, thank you for confirming the code, @robert-w-gries !

[jaypatelani]

Getting error " error: linking with rust-lld failed: exit code: 1" on bootimage build --target x86_64-blog_os.json

[phil-opp]

@jaypatelani Can you give us the full output? Sounds similar to @tyfkda's problem.

@tyfkda Could you solve your problem? Sorry for not responding earlier, I was on vacation.

[phil-opp]

@CRogers

I'm a big fan of the bootimage tool (and cargo-xbuild), these kind of tools are what makes development faster and easier for everyone to get involved. Especially us on OS X - when I last tried to follow a tutorial in rust for an OS I spent the whole time getting cross compilation to work.

Awesome, great to hear that!

[jaypatelani]

@phil-opp here is my error http://pasteall.org/1303510

Also why not made this tutorial with ISC license? :) Thanks for great tutorial

[tyfkda]

@phil-opp , I tried it once again, but same error happened.

In terminal log, is "-flavor" "gnu" the problem? What is it should be?

[phil-opp]

@jaypatelani Ok so the error says that the rust_begin_unwind symbol was not found. Are you using an up-to-date nightly (there were some changes to symbol resolution a while ago)? Are you setting panic to abort either in your target JSON file or your Cargo.toml?

Also why not made this tutorial with ISC license? :)

Why? What's the problem with Apache/MIT?

[phil-opp]

@tyfkda

In terminal log, is "-flavor" "gnu" the problem?

I don't think so, I get the same on my machine. The problem seems to be that the "cannot open output file" part. It looks like you're running it in a virtual machine, maybe it has not enough memory or the output folder has incorrect permissions?

[jaypatelani]

hi, removed "panic = abort" from Cargo.toml but it gives me also have done " cargo update" : error: language item required, but not found: eh_personality
--> for regarding license ISC gives more freedom if someone wants to take it further and make full blown OS :) --> Hope you had great vacation

[tyfkda]

@phil-opp , thank you for your advice. I'll check it out.

[phil-opp]

@jaypatelani I didn't mean that you should remove panic = abort, I just wanted to ensure that you did not forget it. What version of Rust are you using (rustc --version)? Note that cargo update only updates your dependency versions, not the Rust compiler itself. To update the compiler, run rustup update.

for regarding license ISC gives more freedom if someone wants to take it further and make full blown OS :)

More than the MIT/Apache licenses?

Hope you had great vacation

I did, thanks! :)

[jaypatelani]

@phil-opp rustc --version is "rustc 1.31.0-nightly (8c4ad4e9e 2018-10-04)"

[phil-opp]

@jaypatelani I'm using the same nightly but can't reproduce your error. Do you have your code online somewhere so that I can test it with your exact code?

There was a rustc issue in the past that caused this error, but it should be fixed. The old workaround was to add pub and #[no_mangle] to the panic handler function, maybe it helps in your case.

[jaypatelani]

@phil-opp my cargo.toml :https://pastebin.com/xWGdFckX main.rs : https://pastebin.com/u7UVD7e9 json : https://pastebin.com/Mfh3rVsw Thanks

[phil-opp]

@jaypatelani The problem is that you applied the #[panic_handler] attribute to the extern crate definition and not the panic function. Attributes of the form #[…] always apply to the next item. If you move the panic_handler attribute to the panic function, the error no longer occurs: https://pastebin.com/bdEt703K. (I also removed the no_mangle attributes and the pub from panic, because they aren't needed.)

I opened an Rust issue to improve the error message for this case: https://github.com/rust-lang/rust/issues/54896.

[jaypatelani]

@phil-opp Thanks a lot . i got it now :) i need to read more rust.

[phil-opp]

@jaypatelani You're welcome!

[cymno]

Minor detail: The file bootimage.bin in the target/x86_64-blog_os/debug/ directory is currently called bootimage-<crate_name>.bin. The bootimage tool recognizes the file correctly.

[phil-opp]

@cymno Thanks, fixed in 9eef331df63a6aaafa3ee9c2b64771cbdcb49619.

[KD0BPV]

@phil-opp I was just wondering why we still need to mark _start as extern "C" at this point, where our kernel is apparently completely independent of any C code. My guess is that it's because the bootloader calls our kernel using the C calling convention. Is this correct? If so, if we wanted to, we could also make a custom bootloader that uses the Rust convention instead, and our kernel wouldn't need any extern "C" statements, correct?

[0paIescent]

I've got an odd issue, everything builds as it should, but when running in QEMU it gets into a boot loop. It gets to Booting (second stage), and then it loops right back to the beginning over and over. I'm using bootimage v0.5.6 and bootloader_precompiled v0.3.0. Also, here's a link to my Gitlab project which includes my image with it's nifty bootloop feature. https://gitlab.com/Opalescent/hobby-os

[0paIescent]

Nevermind! I just had an extra zero in my vga_buffer address.

[bjorn3]

@KD0BPV Rust doesn't have a defined calling convention, so you have to use extern "C".

[KD0BPV]

Ah. Ok. So, am I right about our kernel needing to match the calling convention used by the bootloader, then?

[bjorn3]

Yes, or there shall be nasal demons. 😄

[rmw2]

Hey @phil-opp, love the series! I've gone through the 2e posts, and most of the 1e, and am just a tiny bit confused about exactly what the bootloader leaves us with. Reading through the bootloader crate, it looks like it sets up the memory_map, enables paging, and even defines a context_switch asm routine. Is that page table still in use after we load the kernel elf file? If we wanted to set up our own page table (with the current setup), would that have to be done in the bootloader stage, or could we reconfigure it after the kernel is loaded? Relatedly, can we call to any of the rust code in the bootloader crate from our kernel, or is it compiled separately?

Thanks!

[phil-opp]

@rmw2 Hi! The bootloader initializes the CPU into long mode, loads the kernel from disk and creates a fine-grained page table mapping for it that already sets the correct access flags for the individual pages. It also creates a guard page for the stack. So it provides a safe initial execution environment for our kernel, where out of bounds accesses and stack overflows lead to access violations.

Calling back into the bootloader from the kernel is not intended. Instead, the bootloader passes a &'static Bootinfo as argument to the _start function. It is not documented yet, but the p4_table_addr field contains a recursively mapped address that gives you access to the P4 table. This allows you to change the page table entries, e.g. through the RecursivePageTable type of the x86_64 crate.

I hope this helps! I try my best to cover these things in the blog soon.

[ryanyz10]

Hi @phil-opp, great tutorials! I'm currently in OS in college but wanted to go back and spend some more time on certain aspects of the operating system in Rust.

I'm currently having some trouble getting text to display with QEMU. I'm on MacOS 10.14, and when I run qemu-system-x86_64 -drive format=raw,file=bootimage-toy_os.bin, there is no output. No text is printed and no errors are displayed. Any ideas? I installed qemu with brew.

Edit: never mind, I didn't realize qemu opened in another window.

[phil-opp]

@ryanyz10 Thanks! Yes, QEMU opens in a separate window.

[berkus]

Hmm, so I cannot use bootimage if I want to develop for something else than x86_64 pc, right? How can I specify my own bootloader (or no need for it) in that case?