Added arm-none-eabi target #60135
Closed
Added arm-none-eabi target #60135
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Centril
added
relnotes
|
@japaric or @jamesmunns can y'all comment on this perhaps? I suspect this is highly related to the embedded WG! |
|
I think @japaric is going to know more than I will, but I have a couple initial comments. Regarding Naming: If this is for Cortex-A targets, this covers a couple of different possible targets, particularly spanning the ARMv7A and ARMv8A architectures, as well as 32 vs 64 bit targets. I can't remember what LLVM's naming scheme is exactly (we have armv7- for 32 bit and aarch64 for 64 bit targets), and I think the Depending on the answers above, this might need to be split into a couple targets, such as:
Again, not sure if all of the items above are actually "real" targets. Regarding lld, we are defaulting to that for bare metal targets if lld supports them well. I would expect this to be the case for Cortex-A targets, so I would suggest starting with that if possible. I'm not sure about the CI/x.py tooling, that's not something I touch often enough to know off the top of my head. You can definitely grep around for what some of the other bare metal targets like the thumb* targets do in these cases. CC also maybe @posborne and @SergioBenitez, who have done bare metal Cortex-A things in the past. |
|
Edit, oops, I meant to tag @phil-opp, rather than Paul (sorry for the noise). @andre-richter is also probably a good person to tag regarding ARM Cortex-A, or anyone from the Cortex-A team on the embedded-wg. |
jamesmunns
reviewed
Apr 22, 2019
| features: "+strict-align,+v6".to_string(), | ||
| executables: true, | ||
| relocation_model: "static".to_string(), | ||
| max_atomic_width: Some(64), |
There was a problem hiding this comment.
Do the 32 bit targets support 64 bit atomics?
There was a problem hiding this comment.
According to other arm-* targets, it does
|
Bare metal aarch64 targets exist already, so I don't think it's relevant. As for v6, I assumed I should match other hosted arm targets, and that you'd be able (as a user) to specify either your exact CPU or a feature set. Edit: I looked at it and it seems Arm-V6 are mostly old legacy CPUs that can probably be targeted by one of the thumb targets. I wonder about other arm targets and why don't they specify +v7. Even if we do, should we keep the name to match the gcc/llvm target? |
|
It looks like the current state of arm targets is that there is both an arm_unknown_linux_gnueabi[hf] and armv7_unknown_linux_gnueabihf. We can probably add none targets to both, though I'm not sure anymore of the significance of the former. |
|
FWIW, the naming of the rust I suspect the target you are wanting to add is |
|
I am running on v7 cores using hard-float, but I'm not really using any fp-operations so it doesn't really matter to me. I've replaced the arm-none-eabi target with armv7-none-eabihf. (seeing as there's no other armv7- target that is without hard-float). I'm sure there's somewhere I can specify these variables inside the toolchain, but I can't find it. |
|
This is probably a good time to streamline the naming of the ARM bare metal targets before we bring in a new one with yet a different naming. We already have the Unfortunately, I think https://github.com/rust-embedded/rust-raspi3-OS-tutorials is one of the few, if not the only "popular" user of I am unsure who should make the call, though. Probably @parched due to his affiliation ;) |
| // For example, `-C target-cpu=cortex-a7`. | ||
|
|
||
| use crate::spec::{LinkerFlavor, LldFlavor, PanicStrategy, Target, TargetOptions, TargetResult}; | ||
|
|
There was a problem hiding this comment.
You probably want +strict-align for bare-metal.
It can bite you with a hard to find bugs if alignment errors happen. Made the experience already: c4e4614
|
My general line of thought was int favour of keeping names same to GCC/LLVM, but I also assumed the scheme was consistent, so I don't have an opinion on the subject anymore. On the one hand, breaking compatibility sounds a bit scary, but then again, it's not like code that wasn't valid/invalid before will be now. |
|
If we base the discussion on http://clang.llvm.org/docs/CrossCompilation.html#general-cross-compilation-options-in-clang, I think we need the Furthermore, for
So far, we would be at What ABI are we even getting here? |
|
I think omitting unknown in this case is for the better, not sure if it adds anything. Out of the currently available none-targets, 12 are simply "none", as opposed to 5 "unknown-none" (of which, 4 are riscv and one is aarch64). More specifically, all other arm or thumb targets are of the former form, and end with either eabi or eabihf |
I agree with this but there are some subtleties here
IMO the target(s) should be called Whether we want an I don't have a strong opinion on whether to include the |
Yes, but there is a total of 8 aarch64 targets which start with How about:
This way, we would be consistent with regards to the |
|
Makes perfect sense, I'll fix the naming when I get home |
bors
added
the
S-waiting-on-bors
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
May 2, 2019
Added arm-none-eabi target Hello, This PR adds a new target for compiling bare-metal ARM Cortex-A programs. I've managed to build and use this new target, but I am unclear with regards to a few details: - I'm not sure what are the criteria for choosing between lld and gnu-ld - When trying to build with `./x.py build --target arm-none-eabi`, the script tries to compile with `cc`, instead of `arm-none-eabi-gcc`. It could find different cross-compilers just fine, but I didn't understand where I had to specify it. (I ended up specifying `CC_arm_none_eabi=arm-none-eabi-gcc` in the environment). - I couldn't find where I can exclude std from compiling for this target (as I guess occurs with other bare-metal targets). - Should I add a separate target for `eabihf`?
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 2, 2019
Added arm-none-eabi target Hello, This PR adds a new target for compiling bare-metal ARM Cortex-A programs. I've managed to build and use this new target, but I am unclear with regards to a few details: - I'm not sure what are the criteria for choosing between lld and gnu-ld - When trying to build with `./x.py build --target arm-none-eabi`, the script tries to compile with `cc`, instead of `arm-none-eabi-gcc`. It could find different cross-compilers just fine, but I didn't understand where I had to specify it. (I ended up specifying `CC_arm_none_eabi=arm-none-eabi-gcc` in the environment). - I couldn't find where I can exclude std from compiling for this target (as I guess occurs with other bare-metal targets). - Should I add a separate target for `eabihf`?
|
⌛ Testing commit c8baec9 with merge d3e91159d42eff4a82cf0b7a55994d4434cecc8c... |
|
💔 Test failed - checks-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
sanxiyn
added
S-waiting-on-author
|
Legitimate failure compiling https://github.com/rust-lang-nursery/compiler-builtins. |
|
Yeah, I'm kinda lost. Not sure where to put the flags to fix this (they're listed above), and couldn't find someone to tell me. |
|
@bors r- since legitimate failure. |
|
Sorry, I don't have the time or knowledge to fix this |
Centril
removed
the
relnotes
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 27, 2019
…=Amanieu Differentiate AArch64 bare-metal targets between hf and non-hf. CC @parched, kindly request you to review. ~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~ ~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late. Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~ ---------- Patch commit message: Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] rust-lang#60135 (comment) [2] rust-embedded/wg#230 Closes: rust-embedded/wg#230
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 28, 2019
…=Amanieu Differentiate AArch64 bare-metal targets between hf and non-hf. CC @parched, kindly request you to review. ~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~ ~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late. Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~ ---------- Patch commit message: Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] rust-lang#60135 (comment) [2] rust-embedded/wg#230 Closes: rust-embedded/wg#230
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 28, 2019
…=Amanieu Differentiate AArch64 bare-metal targets between hf and non-hf. CC @parched, kindly request you to review. ~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~ ~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late. Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~ ---------- Patch commit message: Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] rust-lang#60135 (comment) [2] rust-embedded/wg#230 Closes: rust-embedded/wg#230
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 29, 2019
…=Amanieu Differentiate AArch64 bare-metal targets between hf and non-hf. CC @parched, kindly request you to review. ~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~ ~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late. Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~ ---------- Patch commit message: Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] rust-lang#60135 (comment) [2] rust-embedded/wg#230 Closes: rust-embedded/wg#230
andjo403
pushed a commit
to andjo403/rust
that referenced
this pull request
Oct 4, 2019
Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without hardware floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] rust-lang#60135 (comment) [2] rust-embedded/wg#230 Closes: rust-embedded/wg#230
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
This PR adds a new target for compiling bare-metal ARM Cortex-A programs.
I've managed to build and use this new target, but I am unclear with regards to a few details:
./x.py build --target arm-none-eabi, the script tries to compile withcc, instead ofarm-none-eabi-gcc. It could find different cross-compilers just fine, but I didn't understand where I had to specify it. (I ended up specifyingCC_arm_none_eabi=arm-none-eabi-gccin the environment).eabihf?