Long mode #8

japaric · 2016-09-18T16:30:28Z

cc @steveklabnik @phil-opp

closes #6 closes #7

japaric · 2016-09-18T16:30:40Z

@homunkulus try

homunkulus · 2016-09-18T16:30:41Z

⌛ Trying commit bcc0c6a with merge bcc0c6a...

homunkulus · 2016-09-18T16:33:36Z

💔 Test failed - status-travis

japaric · 2016-09-18T16:34:18Z

README.md

+  accessed via pure Rust, AFAIK. For that reason, this part is written in inline assembly.
+- Caveat: Because we are telling `rustc` to use a 32-bit target, `rustc` always emit 32-bit
+  instructions and we can't actually use 64-bit instructions/registers in the section of the program
+  where the CPU is already in long mode. Yikes, I'll have to think about how to solve this.


I think this can be solved by splitting this crate in two: one crates that does the booting process and is compiled for a 32-bit target and the other crate that exposes the long_mode_start symbol and is compiled for a 64-bit target. The issue is that I think the compiler won't link together crates compiled for different types (imagine mixing a crate compiled for ARM with a crate compiled for x86). If that's the case we could compiled the boot crate as a staticlib and link that staticlib into the long crate. That should bypass the "same target" check.

All this is speculation from my part. I don't know if it will actually work.

That sounds about right to me.

the target changed

japaric · 2016-09-18T16:35:35Z

@homunkulus try

homunkulus · 2016-09-18T16:35:37Z

⌛ Trying commit 2ed58d5 with merge 2ed58d5...

japaric · 2016-09-18T16:37:00Z

src/main.rs

+    // extra selector
+    asm!("mov es, ax" :::: "intel");
+
+    // FIXME Is this the right syntax for a far jump?


Thought on this part?

I think so? Not 100% sure though.

homunkulus · 2016-09-18T16:38:24Z

💔 Test failed - status-travis

it fails to link for some reason :-/

japaric · 2016-09-18T16:39:56Z

@homunkulus try

homunkulus · 2016-09-18T16:39:58Z

⌛ Trying commit 137b345 with merge 137b345...

homunkulus · 2016-09-18T16:43:08Z

☀️ Test successful - status-travis
State: approved= try=True

steveklabnik · 2016-09-18T16:54:49Z

README.md

+  accessed via pure Rust, AFAIK. For that reason, this part is written in inline assembly.
+- Caveat: Because we are telling `rustc` to use a 32-bit target, `rustc` always emit 32-bit
+  instructions and we can't actually use 64-bit instructions/registers in the section of the program
+  where the CPU is already in long mode. Yikes, I'll have to think about how to solve this.


That sounds about right to me.

steveklabnik · 2016-09-18T16:55:38Z

src/main.rs

+
+    // move page table address to cr3
+    asm!("mov eax, p4_table
+          mov cr3, eax" :::: "intel");


https://crates.io/crates/x86 would be neat to use here, but it also only supports 64-bit for now, IIRC.

They added support for 32 bit lately, but I'm not sure if it's already on crates.io…

0.8 on crates.io has the bulk of this.

steveklabnik · 2016-09-18T16:55:57Z

src/main.rs

+    // extra selector
+    asm!("mov es, ax" :::: "intel");
+
+    // FIXME Is this the right syntax for a far jump?


I think so? Not 100% sure though.

steveklabnik · 2016-09-23T17:46:55Z

A thought that I've been rolling around in my head, but haven't tried to implement yet.

What about having a build.rs that builds an asm implementation of the booting into long mode? Treat it like any other dependency. It should basically never change, but even if it does, the rerun-if-changed bit could fix it. Then, the Rust code is all x86-64.

japaric · 2016-09-23T18:48:32Z

@steveklabnik That would have to shell out to an external assembler like nasm, right? I would prefer if we didn't have to depend on an external tool but, yes, that should work in principle.

steveklabnik · 2016-09-23T18:50:33Z

Yeah, it would still require shelling out. It's not a perfect solution, but
it still lets you get rid of the makefile.

Even worse idea: one huge "inline asm" Rust block? lololol

On Fri, Sep 23, 2016 at 2:48 PM, Jorge Aparicio [email protected]
wrote:

@steveklabnik https://github.com/steveklabnik That would have to shell
out to an external assembler like nasm, right? I would prefer if we
didn't have to depend on an external tool but, yes, that should work in
principle.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABsih7FQ6mQTGGxofMB73wJn4X8Y5aIks5qtB8BgaJpZM4J_8bw
.

japaric · 2016-09-23T18:52:29Z

Another approach that could work is have a single x86_64 target, split the boot code into its own crate, compile that boot crate for x86_64 but use -C target-feature to force the use of 32-bit instructions in that crate and, finally, link that crate with the kernel crate which is compiled normally (in 64-bit mode).

I tried this but I couldn't figure a combination of target-features that produces only 32-bit instructions. +32bit-mode,-64bit,-64bit-mode looked promising but it resulted in an LLVM assertion.

japaric · 2016-09-23T18:54:24Z

Even worse idea: one huge "inline asm" Rust block? lololol

👍. I have actually thought about this! I think it requires global asm instead of inline though (I haven't actually tried)

steveklabnik · 2016-09-23T19:04:28Z

I bet you could configure start? Hm.

On Fri, Sep 23, 2016 at 2:54 PM, Jorge Aparicio [email protected]
wrote:

Even worse idea: one huge "inline asm" Rust block? lololol

👍. I have actually thought about this! I think it requires global asm
instead of inline though (I haven't actually tried)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABsij54rb9qbfGotAfAIAfmohOdNX0cks5qtCBhgaJpZM4J_8bw
.

phil-opp · 2016-09-23T19:15:10Z

A naked extern function with #[no_mangle] should work. However, I'm not sure if inline assembly supports the bits 32 directive, which we use to generate 32 bit opcodes in nasm...

Ericson2314 · 2016-09-23T23:41:14Z

I'm guessing a similar situation arises when using arm's dynamic endianness to mix ABIs. To me this is proof that the problem is general enough that Cargo should get a proper solution for this.

I do believe baking exact targets into packages is bad, so I guess the solution would be "chameleon targets" that change their definition based on the crate being built? On the other hand two such crates may share the same dependency in which case it is should be configured (flags) + compiled differently, so naive per-crate target shape-shifting won't work.

steveklabnik · 2016-09-26T15:45:57Z

I implemented the "build using nasm in a build script" over here: intermezzOS/kernel#63

That nasty build script can be made much nicer with the gcc crate, but then you have to use a syntax gcc understands, which isn't nasm. and i haven't taken the time to port it over yet.

I still find #8 (comment) very interesting

steveklabnik · 2016-09-26T15:58:29Z

So, I'm giving that idea a try. I got a libboot.a compiled from the rust in this PR, but when trying to make my other code depend on it, I'm getting

= note: /usr/bin/ld: skipping incompatible ./libboot.a when searching for -lboot

So, something must be slightly off. But I think this might work?

steveklabnik · 2016-09-26T16:14:56Z

So, @mkpankov pointed out this:

$ readelf -h libboot.a 

File: libboot.a(boot.0.o)
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32

It's going to know that it's a 32-bit ELF file, and not link it in. Given this,

Another approach that could work is have a single x86_64 target, split the boot code into its own crate, compile that boot crate for x86_64 but use -C target-feature to force the use of 32-bit instructions in that crate and, finally, link that crate with the kernel crate which is compiled normally (in 64-bit mode).

Seems like it's probably the correct approach.

steveklabnik · 2016-09-26T18:33:07Z

Regarding the "can inline asm do BITS 32", I got a tweet that says yes: https://twitter.com/rpjohnst/status/780474494066450433

japaric · 2016-09-26T19:26:23Z

@steveklabnik did the libboot.a approach work in the end? I tried the two targets, x86 and x86_64, approach and hitted the same problem: the libboot.a (a rust crate compiled as a staticlib) compiled for x86 was a 32-bit elf/library and got ignored by the linker when I tried to link it to the x86_64 kernel crate.

Seems like it's probably the correct approach.

Yeah, but LLVM isn't cooperating :-/.

steveklabnik · 2016-09-26T20:37:32Z

I couldn't get it to work, due to the 64/32 issue.

steveklabnik · 2016-09-26T20:38:16Z

One other idea I had: if we converted into intel syntax rather than nasm-specific, we could just use the gcc crate to build it. rust already uses gcc for the linker, so that would eliminate one more dep...

steveklabnik · 2016-10-12T17:58:57Z

src/main.rs

+    p4_table[0] = &p3_table[0] as *const _ as usize as u64 | 0b11;
+    p3_table[0] = &p2_table[0] as *const _ as usize as u64 | 0b11;
+
+    for (entry, i) in p2_table.iter_mut().zip(0..) {


.enumerate() rather than zip(0 ?

Jorge Aparicio added 3 commits September 17, 2016 21:23

re-build the kernel if the linker script changed

8252572

panic=abort

f5d99cf

jump into long mode

bcc0c6a

closes #6 closes #7

japaric commented Sep 18, 2016

View reviewed changes

update .travis.yml

2ed58d5

the target changed

japaric commented Sep 18, 2016

View reviewed changes

travis: don't build in debug mode

137b345

it fails to link for some reason :-/

steveklabnik approved these changes Sep 18, 2016

View reviewed changes

steveklabnik reviewed Oct 12, 2016

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Long mode #8

Long mode #8

japaric commented Sep 18, 2016

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

homunkulus commented Sep 18, 2016

japaric Sep 18, 2016

steveklabnik Sep 18, 2016

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

japaric Sep 18, 2016

steveklabnik Sep 18, 2016

homunkulus commented Sep 18, 2016

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

homunkulus commented Sep 18, 2016

steveklabnik Sep 18, 2016

steveklabnik Sep 18, 2016

phil-opp Sep 18, 2016

Ericson2314 Sep 23, 2016

steveklabnik Sep 18, 2016

steveklabnik commented Sep 23, 2016

japaric commented Sep 23, 2016

steveklabnik commented Sep 23, 2016

japaric commented Sep 23, 2016

japaric commented Sep 23, 2016

steveklabnik commented Sep 23, 2016

phil-opp commented Sep 23, 2016

Ericson2314 commented Sep 23, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

japaric commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik Oct 12, 2016

Long mode #8

Are you sure you want to change the base?

Long mode #8

Conversation

japaric commented Sep 18, 2016

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

homunkulus commented Sep 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

homunkulus commented Sep 18, 2016

japaric commented Sep 18, 2016

homunkulus commented Sep 18, 2016

homunkulus commented Sep 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik commented Sep 23, 2016

japaric commented Sep 23, 2016

steveklabnik commented Sep 23, 2016

japaric commented Sep 23, 2016

japaric commented Sep 23, 2016

steveklabnik commented Sep 23, 2016

phil-opp commented Sep 23, 2016

Ericson2314 commented Sep 23, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

japaric commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

steveklabnik commented Sep 26, 2016

Choose a reason for hiding this comment