Skip to content
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 sparc64-unknown-netbsd target #38656

Closed

Conversation

jakllsch
Copy link
Contributor

No description provided.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (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.

@japaric
Copy link
Member

japaric commented Dec 28, 2016

LGTM. (Except for the cabi stuff; I can't really review that. But if it looks like the cabi of other 64-bit target, it should be OK-ish)

Can you (cross) compile std with this PR? No libc changes were required? (That seems odd)

@jakllsch
Copy link
Contributor Author

@japaric:

The cabi_sparc64 stuff was copy and pasted from cabi_powerpc64, and then modified to always assume big endian.

The rust-libc stuff for sparc64-unknown-netbsd was merged three weeks ago: rust-lang/libc#467.

@japaric
Copy link
Member

japaric commented Dec 28, 2016

The rust-libc stuff for sparc64-unknown-netbsd was merged three weeks ago: rust-lang/libc#467.

Great! I hope that the libc changes for sparc64-linux will be as simple as that (likely not).

Can std for this target be cross compiled from Linux? Or only from x86_64 netbsd?

@jakllsch
Copy link
Contributor Author

@japaric: I believe I've compiled std for sparc64-unknown-netbsd before from x86_64-unknown-linux-gnu. I'm checking again though. It appears I've got a few more patches that may be required for it to all work. Also required would be a NetBSD cross toolchain and some wrapper scripts for the three cross tools. I need to document my setup... The basic procedure is to use NetBSD's build.sh to cross-build a distrubtion, and then wrap the gcc, and g++ tools adding the --sysroot= argument to point the compilers at the destdir for the platform. These two wrappers, as well as a no-argument-adjustment wrapper for ar should be given the names expected by the gcc-rs crate and placed in the $PATH.

@bors
Copy link
Contributor

bors commented Dec 30, 2016

☔ The latest upstream changes (presumably #38697) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Dec 31, 2016

☔ The latest upstream changes (presumably #38701) made this pull request unmergeable. Please resolve the merge conflicts.

@japaric japaric mentioned this pull request Dec 31, 2016
bors added a commit that referenced this pull request Jan 1, 2017
sparc64-linux support

This is built on top of #38656 and depends on rust-lang/libc#483

Hello world works.

The libc-test test suite passes.

`panic!` doesn't fully work:

```
$ qemu-sparc64-static ./panic
thread 'main' panicked at 'explicit panic', panic.rs:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Illegal instruction (core dumped)
```

Backtraces don't work either, probably related to the previous point:

```
$ export RUST_BACKTRACE=1
$ qemu-sparc64-static ./panic
thread 'main' panicked at 'explicit panic', panic.rs:1
stack backtrace:
Illegal instruction (core dumped)
```

r? @alexcrichton

@jakllsch Does panicking / backtraces work on sparc64-netbsd?

cc @glaubitz
@sanxiyn
Copy link
Member

sanxiyn commented Jan 1, 2017

Merged in #38726.

@sanxiyn sanxiyn closed this Jan 1, 2017
@alexcrichton
Copy link
Member

@sanxiyn this PR was not approved before it was merged, did you intend to merge this?

@sanxiyn
Copy link
Member

sanxiyn commented Jan 2, 2017

Yes.

@brson
Copy link
Contributor

brson commented Jan 3, 2017

@sanxiyn it's a bit confusing what happened here since you pushed to someone else's branch. In the future can you leave a comment explaining what you are doing, and r+ prs before merging them?

@Mark-Simulacrum
Copy link
Member

As I understand it, this PR was used by @japaric as a base for #38726, which means that its contents were merged with the approval of that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants