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

targets: thumbv8m: Add target for baseline ARMv8-M #55041

Merged
merged 3 commits into from
Dec 4, 2018
Merged

Conversation

evq
Copy link
Contributor

@evq evq commented Oct 13, 2018

Tested against a SAM L11 MCU.

@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 @petrochenkov (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.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2018
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:05:05] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:05:05] tidy error: /checkout/src/librustc_target/spec/thumb_base.rs:22: line longer than 100 chars
[00:05:06] some tidy checks failed
[00:05:06] 
[00:05:06] 
[00:05:06] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:06] 
[00:05:06] 
[00:05:06] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:06] Build completed unsuccessfully in 0:00:51
[00:05:06] Build completed unsuccessfully in 0:00:51
[00:05:06] make: *** [tidy] Error 1
[00:05:06] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0940fbe6
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:05d34fae:start=1539442964730110438,finish=1539442964734425755,duration=4315317
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0b504788
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:2e336dbb
travis_time:start:2e336dbb
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:16b7a2a4
$ dmesg | grep -i kill

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 @TimNN. (Feature Requests)

@@ -397,6 +397,7 @@ supported_targets! {
("thumbv7m-none-eabi", thumbv7m_none_eabi),
("thumbv7em-none-eabi", thumbv7em_none_eabi),
("thumbv7em-none-eabihf", thumbv7em_none_eabihf),
("thumbv8m-none-eabi", thumbv8m_none_eabi),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thumbv8m.base-none-eabi would be better to distinguish from a thumbv8m.main target in the future.

target_vendor: String::new(),
linker_flavor: LinkerFlavor::Lld(LldFlavor::Ld),

options: TargetOptions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The baseline architecture doesn't support unaligned access, so features: "+strict-align".to_string(), will need to be added here as I believe it's not enabled by default.

Copy link
Contributor

@petrochenkov petrochenkov Oct 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, it looks like the "Main Extension" from 8-M was a baseline in 7-M? And this newly added target (used for Cortex-M23) is not really a baseline but mainline?

Any other notable changes in 8-M affecting codegen? The "changelog" in ARM ARM doesn't tell much to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! Good catch @parched, I will adjust.

I took a look at this description of changes here: https://community.arm.com/processors/trustzone-for-armv8-m/b/blog/posts/five-key-features-of-the-arm-cortex-m23-processor?CommentId=f95326ae-7e58-4829-9874-a1ebd4a141e9

I think I may have atomic instruction support incorrectly configured. Per the above blog post:

In addition, to provide atomic support for C11/C++11, the load-acquire and store-release instructions are included from ARMv8-A

There is no mention of atomic CAS support, I think that I may need to set atomic_cas: false while keeping max_atomic_width: Some(32),. https://reviews.llvm.org/D15283?id=42050 also seems to hint at this. Does this seem correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I may have atomic instruction support incorrectly configured.

No, you have it correct already :).

ARMv8-M Baseline is a superset of ARMv6-M, containing all ARMv6-M instructions plus ARMv8-A semaphores and atomics, ARMv7-M exclusives

This is what gives it CAS support.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 13, 2018
@petrochenkov
Copy link
Contributor

LGTM beside figuring out this baseline vs mainline distinction new to ARMv8-M.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:05:16]    Compiling flate2 v1.0.3
[00:05:16]    Compiling backtrace v0.3.9
[00:05:18]    Compiling crossbeam-deque v0.2.0
[00:05:21]    Compiling rustc-rayon v0.1.1
[00:05:22] error: no rules expected the token `.`
[00:05:22]     |
[00:05:22]     |
[00:05:22] 400 |     ("thumbv8m.base-none-eabi", thumbv8m.base_none_eabi),
[00:05:22] 
travis_time:end:04d140e3:start=1539925363888306447,finish=1539925689002220123,duration=325113913676

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
---
travis_time:end:1cfd1c1f:start=1539925689446617305,finish=1539925689452220821,duration=5603516
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:081fced6
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0769a37d
travis_time:start:0769a37d
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynam

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 @TimNN. (Feature Requests)

@japaric
Copy link
Member

japaric commented Oct 19, 2018

Target stuff LGTM.

While testing this I noticed that Cargo puts the artifacts in target/thumbv8m/{debug,release}; the target name gets cut at the dot (.). That seems to indicate that a future thumbv8m.main-none-eabi target will use the same build directory possibly leading to collisions.

Before landing this I'd like to check with the @rust-lang/cargo team whether Cargo can be modified to support dots in target names. Or if we should choose a target name without a dot in it.

@alexcrichton
Copy link
Member

Would it be possible to not use a dot in the target name? It deviates a bit from our naming of other targets, and yeah I think Cargo assumes that anything with a . is a custom target spec that ends in JSON, so it only uses what's before the . as the target directory

@parched
Copy link
Contributor

parched commented Oct 19, 2018

Would it be possible to not use a dot in the target name?

Yes it would, but that would be deviating from the target clang uses and what -march accepts. Wouldn't it be better to fix cargo to look for .json instead of .?

@alexcrichton
Copy link
Member

Perhaps! I'd be fine with either fix

@petrochenkov
Copy link
Contributor

r? @alexcrichton

@evq
Copy link
Contributor Author

evq commented Oct 31, 2018

It deviates a bit from our naming of other targets, and yeah I think Cargo assumes that anything with a . is a custom target spec that ends in JSON, so it only uses what's before the . as the target directory

@alexcrichton can you point me to where this happens in Cargo? happy to open up a PR - I like the idea of matching the clang target name

@alexcrichton
Copy link
Member

I think it's around here

@TimNN
Copy link
Contributor

TimNN commented Nov 13, 2018

Ping from triage @evq: What is the status of this PR?

@Dylan-DPC-zz
Copy link

@evq pinging from triage. Thanks for the PR. Unfortunately we haven't heard from you on this in a while, so I'm closing the PR to keep things tidy. Don't worry though, if you'll have time again in the future please reopen this PR, we'll be happy to review it again!

@Dylan-DPC-zz Dylan-DPC-zz added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 19, 2018
@caemor
Copy link

caemor commented Nov 19, 2018

@Dylan-DPC I think this is still waiting on rust-lang/cargo#6255 (similar to #56000 )

@petrochenkov petrochenkov added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. labels Nov 19, 2018
@petrochenkov
Copy link
Contributor

Reopening as blocked.

@petrochenkov petrochenkov reopened this Nov 19, 2018
@Dylan-DPC-zz
Copy link

@caemor thanks. will reopen it.

bors added a commit to rust-lang/cargo that referenced this pull request Nov 25, 2018
Tweak Layout to allow for non json file targets with internal "."

Per @alexcrichton 's comment in rust-lang/rust#55041 (comment), currently cargo assumes that a target with an internal `.` is a custom json target spec, using the file stem for the build directory name.

This PR changes cargo to only use the file stem for files with a `json` extension.
@nagisa
Copy link
Member

nagisa commented Dec 2, 2018

The cargo PR has landed.

@nagisa
Copy link
Member

nagisa commented Dec 2, 2018

I’m not sure there is anything blocking this PR from landing except perhaps that the cargo submodule might need updating? I’ve never seen cargo submodule being updated in a regular PR before, so I don’t think it is necessary, but I might be wrong…

@ehuss
Copy link
Contributor

ehuss commented Dec 2, 2018

@nagisa There is a cargo update PR at #56224 that contains the update, hopefully it should make it through today.

@alexcrichton
Copy link
Member

Ok with Cargo fixes merged I'm gonna go ahead and r+ this. While the "usability interface" through Cargo for this target relies on the Cargo fix merging, this change itself technically does not. As a result should be fine for them to land in parallel!

Thanks for the patience @evq!

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Dec 3, 2018

📌 Commit 8a0666d has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Dec 3, 2018
@bors
Copy link
Contributor

bors commented Dec 3, 2018

⌛ Testing commit 8a0666d with merge c8ae2de...

bors added a commit that referenced this pull request Dec 3, 2018
targets: thumbv8m: Add target for baseline ARMv8-M

Tested against a SAM L11 MCU.
@bors
Copy link
Contributor

bors commented Dec 4, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing c8ae2de to master...

@bors bors merged commit 8a0666d into rust-lang:master Dec 4, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Dec 7, 2018
Add Armv8-M Mainline targets

This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
  - `thumbv8m.main-none-eabi`
  - `thumbv8m.main-none-eabihf`

The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.

It follows rust-lang#55041 which does it for Baseline. I will rebase this branch on top of it when it is merged to not create conflicts as we have some files in common. To make it work, it still relies on the Cargo change to be merged (accepting "." in target names, rust-lang/cargo#6255).

The goal would also be to add this target in the CI so that the `core` library is available for everybody. To do this, some changes will be needed to compile successfully the needed libraries:

* `cc-rs` needs to be updated to allow compiling C code for Armv8-M architectures profiles. It is only a few lines to add [here](https://github.com/alexcrichton/cc-rs/blob/a76611ad9836fa8c44fa8220a1d2a96dd3b7d4b6/src/lib.rs#L1299).
* Some assembly files in `builtins` in `compiler-rt` were not assembling for Armv8-M Mainline. I sent changes [upstream](https://reviews.llvm.org/D51854) to that project to fix that. The Rust version of `compiler-rt` will have to be updated to contain [that commit](llvm-mirror/compiler-rt@a34cdf8).

I tested it using the [Musca-A Test Chip board](https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board) but more intensively on the [Armv8-M FVP](https://developer.arm.com/products/system-design/fixed-virtual-platforms) (emulation platform). I am going to try to release my test code soon, once I tidy it up 👍
@tarcieri
Copy link
Contributor

tarcieri commented May 25, 2019

I was able to use the thumbv8m.base-none-eabi target installed via rustup (and with it, blink an LED), however I noticed it's only available on nightly, whereas thumbv8m.main-none-eabi is available on stable. I was curious why (knowing nothing about how targets wind up on stable).

Any way to get this built on stable?

(Edit: It looks like they may have just semi-recently landed on nightly? In which case I hope they'll show up on stable soon)

tarcieri added a commit to tarcieri/atsaml11xxx that referenced this pull request May 25, 2019
I was able to get the blinky example to build and run on a
SAML11 Xplained board with these changes.

Looks like you were able to upstream the `thumbv8m.base-none-eabi`
target definition:

rust-lang/rust#55041

I was able to use that via rustup on a recent nightly, so no more need
for (patched) xargo.

I went ahead and bumped all of the crates to the latest releases as I
wasn't able to get anything to compile without doing so.

All that said, I was able to blink an LED on a SAML11 Xplained.
@hug-dev
Copy link
Contributor

hug-dev commented Jun 3, 2019

I was able to use the thumbv8m.base-none-eabi target installed via rustup (and with it, blink an LED), however I noticed it's only available on nightly, whereas thumbv8m.main-none-eabi is available on stable. I was curious why (knowing nothing about how targets wind up on stable).

I don't know much either how the promotion from nightly to stable works but the thumbv8m.base-none-eabi target was added on the CI around 4 month later than the thumbv8m.main-none-eabi target so maybe that's why we need to wait a bit more?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.