]> git.proxmox.com Git - rustc.git/blob - vendor/rustc-ap-rustc_target/src/spec/thumb_base.rs
New upstream version 1.52.1+dfsg1
[rustc.git] / vendor / rustc-ap-rustc_target / src / spec / thumb_base.rs
1 // These `thumbv*` targets cover the ARM Cortex-M family of processors which are widely used in
2 // microcontrollers. Namely, all these processors:
3 //
4 // - Cortex-M0
5 // - Cortex-M0+
6 // - Cortex-M1
7 // - Cortex-M3
8 // - Cortex-M4(F)
9 // - Cortex-M7(F)
10 // - Cortex-M23
11 // - Cortex-M33
12 //
13 // We have opted for these instead of one target per processor (e.g., `cortex-m0`, `cortex-m3`,
14 // etc) because the differences between some processors like the cortex-m0 and cortex-m1 are almost
15 // non-existent from the POV of codegen so it doesn't make sense to have separate targets for them.
16 // And if differences exist between two processors under the same target, rustc flags can be used to
17 // optimize for one processor or the other.
18 //
19 // Also, we have not chosen a single target (`arm-none-eabi`) like GCC does because this makes
20 // difficult to integrate Rust code and C code. Targeting the Cortex-M4 requires different gcc flags
21 // than the ones you would use for the Cortex-M0 and with a single target it'd be impossible to
22 // differentiate one processor from the other.
23 //
24 // About arm vs thumb in the name. The Cortex-M devices only support the Thumb instruction set,
25 // which is more compact (higher code density), and not the ARM instruction set. That's why LLVM
26 // triples use thumb instead of arm. We follow suit because having thumb in the name let us
27 // differentiate these targets from our other `arm(v7)-*-*-gnueabi(hf)` targets in the context of
28 // build scripts / gcc flags.
29
30 use crate::spec::{LinkerFlavor, LldFlavor, PanicStrategy, RelocModel, TargetOptions};
31
32 pub fn opts() -> TargetOptions {
33 // See rust-lang/rfcs#1645 for a discussion about these defaults
34 TargetOptions {
35 linker_flavor: LinkerFlavor::Lld(LldFlavor::Ld),
36 executables: true,
37 // In most cases, LLD is good enough
38 linker: Some("rust-lld".to_string()),
39 // Because these devices have very little resources having an unwinder is too onerous so we
40 // default to "abort" because the "unwind" strategy is very rare.
41 panic_strategy: PanicStrategy::Abort,
42 // Similarly, one almost always never wants to use relocatable code because of the extra
43 // costs it involves.
44 relocation_model: RelocModel::Static,
45 unsupported_abis: super::arm_base::unsupported_abis(),
46 // When this section is added a volatile load to its start address is also generated. This
47 // volatile load is a footgun as it can end up loading an invalid memory address, depending
48 // on how the user set up their linker scripts. This section adds pretty printer for stuff
49 // like std::Vec, which is not that used in no-std context, so it's best to left it out
50 // until we figure a way to add the pretty printers without requiring a volatile load cf.
51 // rust-lang/rust#44993.
52 emit_debug_gdb_scripts: false,
53 // LLVM is eager to trash the link register when calling `noreturn` functions, which
54 // breaks debugging. Preserve LR by default to prevent that from happening.
55 eliminate_frame_pointer: false,
56 ..Default::default()
57 }
58 }