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

Add a thumbv4t-none-eabi target #74419

Merged
merged 12 commits into from
Jul 19, 2020
1 change: 1 addition & 0 deletions src/librustc_target/spec/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -676,6 +676,7 @@ supported_targets! {
("powerpc64-wrs-vxworks", powerpc64_wrs_vxworks),

("mipsel-sony-psp", mipsel_sony_psp),
("thumbv4t-nintendo-gba", thumbv4t_nintendo_gba),
Copy link
Contributor

Choose a reason for hiding this comment

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

The CPU name is a bit odd as the trailing T means thumb support, but I guess this makes sense. You could run ARM instructions on the GBA though, right?

We do support one other ARMv4 target, armv4t-unknown-linux-gnueabi, but I believe that defaults to ARM instructions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah both a32 and t32 are supported, and the system boots in a32 state, but we want as much of the code as possible to be compiled using t32, so we're defaulting to t32. With the instruction set RFC it'll be a lot easier to mix the two, but we'll still want the default to be t32 for any untagged functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh but I see what you mean with the trailing t since the name already starts with thumb.

i guess it could just be thumbv4-nintendo-gba

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I remember now!! it's called thumbv4t-nintendo-gba because the LLVM target string that LLVM uses as the "basis" for this target profile is thumbv4t-none-eabi, and so if they put "thumbv4t" then we should kinda just follow suit.

I remember that somehow I was able to run a command line thing and have LLVM or rustc print a list of all the "known" target strings, but I can't remember how to do that.

Copy link
Contributor

Choose a reason for hiding this comment

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

You mean rustc --print target-list?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorta like that, but I thought that I'd seen a similar command called on LLVM directly. I could be imagining that part.

}

/// Everything `rustc` knows about how to compile for a specific target.
Expand Down
69 changes: 69 additions & 0 deletions src/librustc_target/spec/thumbv4t_nintendo_gba.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
//! Targets the Nintendo Game Boy Advance (GBA),
//! a handheld game device from 2001.
//!
//! Please ping @Lokathor if changes are needed.
//!
//! The 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
Lokathor marked this conversation as resolved.
Show resolved Hide resolved
//!
//! **Important:** This target profile **does not** specify a linker script or the ROM header. You'll still need to provide these yourself to construct a final binary. Generally you'd do this with something like `-Clink-arg=-Tmy_script.ld` and `-Clink-arg=my_crt.o`.

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

pub fn target() -> TargetResult {
Ok(Target {
llvm_target: "thumbv4t-none-eabi".to_string(),
target_endian: "little".to_string(),
target_pointer_width: "32".to_string(),
target_c_int_width: "32".to_string(),
target_os: "none".to_string(),
target_env: "gba".to_string(),
target_vendor: "nintendo".to_string(),
arch: "arm".to_string(),
/* Data layout args are '-' separated:
* little endian
* stack is 64-bit aligned (EABI)
* pointers are 32-bit
* i64 must be 64-bit aligned (EABI)
* mangle names with ELF style
* native integers are 32-bit
* All other elements are default
*/
data_layout: "e-S64-p:32:32-i64:64-m:e-n32".to_string(),
linker_flavor: LinkerFlavor::Ld,
options: TargetOptions {
linker: Some("arm-none-eabi-ld".to_string()),
linker_is_gnu: true,
jonas-schievink marked this conversation as resolved.
Show resolved Hide resolved

// extra args passed to the external assembler
asm_args: vec!["-mcpu=arm7tdmi".to_string(), "-mthumb-interwork".to_string()],

cpu: "arm7tdmi".to_string(),

// minimum extra features, these cannot be disabled via -C
features: "+soft-float,+strict-align".to_string(),

executables: true,

relocation_model: RelocModel::Static,

main_needs_argc_argv: false,

// if we have thread-local storage
has_elf_tls: false,

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

// always just abort
panic_strategy: PanicStrategy::Abort,

// ABIs to not use
unsupported_abis: super::arm_base::unsupported_abis(),

// this is off just like in the `thumb_base`
emit_debug_gdb_scripts: false,

..TargetOptions::default()
},
})
}