-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add mips64-gnu and mips64el-gnu targets #36024
Conversation
With this commit one can build no_core (and probably no_std as well) Rust programs for these targets. It's not yet possible to cross compile std for these targets because rust-lang/libc doesn't know about the mips64 architecture. These targets have been tested by cross compiling the "smallest hello" program (see code below) and then running it under QEMU. ``` rust #![feature(start)] #![feature(lang_items)] #![feature(no_core)] #![no_core] #[link(name = "c")] extern { fn puts(_: *const u8); } #[start] fn start(_: isize, _: *const *const u8) -> isize { unsafe { let msg = b"Hello, world!\0"; puts(msg as *const _ as *const u8); } 0 } #[lang = "copy"] trait Copy {} #[lang = "sized"] trait Sized {} ```
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Nice! I'm always weirded out by the "standard" name of these targets though, first "gnueabihf" now "gnuabi64"! I guess though that if it's what distros are doing... r=me with an audit on the cabi bits. @eddyb do you know of anyone who'd be appropriate to take a look at that? |
Pushed some changes and now this PR let us cross compile std for these targets (I've only tested the big endian target so far). But this now depends on rust-lang/libc#366 |
@@ -77,7 +77,8 @@ const MIN_ALIGN: usize = 8; | |||
#[cfg(all(any(target_arch = "x86", | |||
target_arch = "x86_64", | |||
target_arch = "aarch64", | |||
target_arch = "powerpc64")))] | |||
target_arch = "powerpc64", | |||
target_arch = "mips64")))] | |||
const MIN_ALIGN: usize = 16; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure if these MIN_ALIGN values make sense for the mips64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should, at least on all 64-bit GNU userlands.
@alexcrichton The hard part w/ cabi is knowing the ABI rules. If there's a concise description of the ABI being implemented I can check the code myself - and so can many other |
Ok, I'll r+ once rust-lang/libc#366 lands and the submodule is updated to that merge commit. |
|
||
fn padding_ty(ccx: &CrateContext, align: usize, offset: usize) -> Option<Type> { | ||
if ((align - 1 ) & offset) > 0 { | ||
Some(Type::i32(ccx)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be incorrect, especially if only 64-bit registers are in use.
addressed @eddyb comments. After re-testing, I found out that libc also needs to define SIGSTKSZ, so I opened rust-lang/libc#370. Also, for some reason, I had to change data-layout; I probably forgot to check in the local changes I did while testing this branch before opening this PR. |
@japaric Thanks, I believe that should be enough, unless there's more complex ABI rules needed. |
@japaric do you want to update the submodule here as well? |
@alexcrichton yes, was waiting for rust-lang/libc#370 to land. @bors r=alexcrichton |
📌 Commit bbf2c3c has been approved by |
add mips64-gnu and mips64el-gnu targets With this commit one can build no_core (and probably no_std as well) Rust programs for these targets. It's not yet possible to cross compile std for these targets because rust-lang/libc doesn't know about the mips64 architecture. These targets have been tested by cross compiling the "smallest hello" program (see code below) and then running it under QEMU. ``` rust extern { fn puts(_: *const u8); } fn start(_: isize, _: *const *const u8) -> isize { unsafe { let msg = b"Hello, world!\0"; puts(msg as *const _ as *const u8); } 0 } trait Copy {} trait Sized {} ``` cc #36015 r? @alexcrichton cc @brson The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
update mips64* data-layout I tried to compile some (`#![no_core]`) code for the `mips64` targets on the latest nightly and got ICE's about mismatched data layouts. I updated the data layouts to match the listed llvm defaults. cc @japaric Funnily enough, this seems to be the exact reverse of what @japaric did in 2222d43 as part of rust-lang#36024.
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
cc #36015
r? @alexcrichton
cc @brson
The cabi stuff is likely wrong. I just copied cabi_mips source and changed some
4
s to8
s and32
s to64
s. It was enough to get libc'sputs
to work but I'd like someone familiar with this module to check it.