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

Fix thumbv4t-none-eabi frame pointer setting #99227

Merged
merged 7 commits into from
Jul 30, 2022
Merged
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 19 additions & 4 deletions compiler/rustc_target/src/spec/thumbv4t_none_eabi.rs
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,19 @@
//!
//! Please ping @Lokathor if changes are needed.
//!
//! This target profile assumes that you have the ARM binutils in your path (specifically the linker, `arm-none-eabi-ld`). They can be obtained for free for all major OSes from the ARM developer's website, and they may also be available in your system's package manager. Unfortunately, the standard linker that Rust uses (`lld`) only supports as far back as `ARMv5TE`, so we must use the GNU `ld` linker.
//! This target profile assumes that you have the ARM binutils in your path
//! (specifically the linker, `arm-none-eabi-ld`). They can be obtained for free
//! for all major OSes from the ARM developer's website, and they may also be
//! available in your system's package manager. Unfortunately, the standard
//! linker that Rust uses (`lld`) only supports as far back as `ARMv5TE`, so we
//! must use the GNU `ld` linker.
//!
//! **Important:** This target profile **does not** specify a linker script. You just get the default link script when you build a binary for this target. The default link script is very likely wrong, so you should use `-Clink-arg=-Tmy_script.ld` to override that with a correct linker script.
//! **Important:** This target profile **does not** specify a linker script. You
//! just get the default link script when you build a binary for this target.
//! The default link script is very likely wrong, so you should use
//! `-Clink-arg=-Tmy_script.ld` to override that with a correct linker script.

use crate::spec::{cvs, LinkerFlavor, Target, TargetOptions};
use crate::spec::{cvs, LinkerFlavor, PanicStrategy, RelocModel, Target, TargetOptions};

pub fn target() -> Target {
Target {
Expand Down Expand Up @@ -39,13 +47,20 @@ pub fn target() -> Target {
// minimum extra features, these cannot be disabled via -C
features: "+soft-float,+strict-align".into(),

panic_strategy: PanicStrategy::Abort,
relocation_model: RelocModel::Static,
// suggested from thumb_base, rust-lang/rust#44993.
emit_debug_gdb_scripts: false,
// suggested from thumb_base, with no-os gcc/clang use 8-bit enums
c_enum_min_bits: 8,

main_needs_argc_argv: false,

// don't have atomic compare-and-swap
atomic_cas: false,
has_thumb_interworking: true,

..super::thumb_base::opts()
..Default::default()
Copy link
Member

Choose a reason for hiding this comment

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

I'm a little surprised from the PR description that this doesn't just manually set the frame pointer to "may omit" which thumb_base gets wrong for this specific target, but instead decides not to use thumb_base at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Somehow that didn't even occur to me compared to "give me the real defaults".

Copy link
Member

Choose a reason for hiding this comment

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

I think I'd prefer to see it still use thumb_base and override the changed field, rather than this approach. Unless there's a reason why this specific target is likely to diverge from thumb_base more often than not. I'm not super familiar with what we normally do for target specifications though, so others may disagree.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can set the field here, but either way I'd prefer to not use thumb_base. Then as the target maintainer i have to try and pay attention to changes to an additional thing. Also as a user a person would have to look in 3 places instead of just 2 to understand all the details.

Copy link
Member

Choose a reason for hiding this comment

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

That's understandable, but at the same time, if there is a change to thumb_base that would be applicable here then it could easily be missed. Ultimately, this is a trade-off that's inherent to how we define these target specs, and I'm not sure it makes sense to be inconsistent about inheriting from base specs on the basis of the preference of the target maintainer, but I don't feel strongly about this. I'd like to see what others think.

},
}
}