Skip to content

Conversation

thejpster
Copy link
Contributor

This PR updates some of the arm*-unknown-none target docs, and adds some missing target pages.

aarch64-none-elf and aarch64-none-elf-softfloat

The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.

armv7a-none-eabi and armv7a-none-eabihf

The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.

armv7r-none-eabi and armv7r-none-eabihf

The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and the target page is split from the Big Endian versions. Links are added to the EDWG's support crates for this target.

armebv7r-none-eabi and armveb7r-none-eabihf

The target page is split from the Little Endian versions. No change in maintainers.

I have agreement to add EDWG/T-Arm as maintainers, which was voted upon in their repo.

@rustbot
Copy link
Collaborator

rustbot commented Sep 10, 2025

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 10, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 10, 2025

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

The Rust Embedded Devices Working Group (wg-embedded) Arm Team (t-arm)
agreed to listed as maintainers of:

* aarch64-unknown-none
* aarch64-unknown-none-softfloat
* armv7a-none-eabi
* armv7r-none-eabi
* armv7r-none-eabihf

The aarch64-unknown-none* target didn't have a page so I added it.

wg-embedded t-arm did not want to take over:

* armebv7r-none-eabi
* armebv7r-none-eabihf

So I gave them their own target page. The current maintainer remains.
@thejpster thejpster force-pushed the update-arm-target-docs branch from 8a54175 to faf0e14 Compare September 10, 2025 18:51
@thejpster
Copy link
Contributor Author

Force-pushed with fixed markdown formatting.

@rustbot

This comment has been minimized.

@thejpster thejpster force-pushed the update-arm-target-docs branch from 827e2cd to f1abb70 Compare September 10, 2025 19:31
@rust-log-analyzer

This comment has been minimized.

@lcnr
Copy link
Contributor

lcnr commented Sep 11, 2025

r? @workingjubilee maybe?

@rustbot rustbot assigned workingjubilee and unassigned lcnr Sep 11, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 11, 2025

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

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

I may find more nits but the maintainer assent one is blocking, I think.

View changes since this review

## Start-up and Low-Level Code

The [Rust Embedded Devices Working Group Arm Team] maintain the
[`aarch64-cpu`], which may be useful for writing bare-metal code using this
Copy link
Member

Choose a reason for hiding this comment

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

the aarch64-cpu... what?

I think you mean "crate", or you mean to delete the "the" from the previous line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops. Fixed.


```toml
[target.<your-target>]
linker = "arm-none-eabi-ld"
Copy link
Member

Choose a reason for hiding this comment

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

This does not seem to be the right linker name for aarch64 targets?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct. Fixed.

processor supports a different set of floating-point features than the default
expectations of `fp-armv8`, then these should also be enabled or disabled as
needed with `-C target-feature=(+/-)`. For example,
`-Ctarget-feature=+neon-fp-armv8`.
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't this need a comma?

Suggested change
`-Ctarget-feature=+neon-fp-armv8`.
`-Ctarget-feature=+neon,-fp-armv8`.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair point. I'll remove the example, as I don't think it's actually helpful.


## Target maintainers

* [@chrisnc](https://github.com/chrisnc)
Copy link
Member

Choose a reason for hiding this comment

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

Uhm. Hrm.

@chrisnc Do you assent?

@thejpster I am not sure I have seen an assent by Chris to maintain this specific target variant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The armebv7r and armv7r targets were on the same page, and so I concluded Chris was the maintainer for both. Pretty sure he wrote the page back in 90893e4.

https://doc.rust-lang.org/beta/rustc/platform-support/armv7r-none-eabi.html

@rustbot rustbot 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 Sep 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants