Skip to content

Latest commit

 

History

History
98 lines (81 loc) · 4.87 KB

0131-target-specification.md

File metadata and controls

98 lines (81 loc) · 4.87 KB
Raw

Summary

Note: This RFC discusses the behavior of rustc, and not any changes to the language.

Change how target specification is done to be more flexible for unexpected usecases. Additionally, add support for the "unknown" OS in target triples, providing a minimum set of target specifications that is valid for bare-metal situations.

Motivation

One of Rust's important use cases is embedded, OS, or otherwise "bare metal" software. At the moment, we still depend on LLVM's split-stack prologue for stack safety. In certain situations, it is impossible or undesirable to support what LLVM requires to enable this (on x86, a certain thread-local storage setup). Additionally, porting rustc to a new platform requires modifying the compiler, adding a new OS manually.

Detailed design

A target triple consists of three strings separated by a hyphen, with a possible fourth string at the end preceded by a hyphen. The first is the architecture, the second is the "vendor", the third is the OS type, and the optional fourth is environment type. In theory, this specifies precisely what platform the generated binary will be able to run on. All of this is determined not by us but by LLVM and other tools. When on bare metal or a similar environment, there essentially is no OS, and to handle this there is the concept of "unknown" in the target triple. When the OS is "unknown", no runtime environment is assumed to be present (including things such as dynamic linking, threads/thread-local storage, IO, etc).

Rather than listing specific targets for special treatment, introduce a general mechanism for specifying certain characteristics of a target triple. Redesign how targets are handled around this specification, including for the built-in targets. Extend the --target flag to accept a file name of a target specification. A table of the target specification flags and their meaning:

  • data-layout: The LLVM data layout to use. Mostly included for completeness; changing this is unlikely to be used.
  • link-args: Arguments to pass to the linker, unconditionally.
  • cpu: Default CPU to use for the target, overridable with -C target-cpu
  • features: Default target features to enable, augmentable with -C target-features.
  • dynamic-linking-available: Whether the dylib crate type is allowed.
  • split-stacks-supported: Whether there is runtime support that will allow LLVM's split stack prologue to function as intended.
  • llvm-target: What target to pass to LLVM.
  • relocation-model: What relocation model to use by default.
  • target_endian, target_word_size: Specify the strings used for the corresponding cfg variables.
  • code-model: Code model to pass to LLVM, overridable with -C code-model.
  • no-redzone: Disable use of any stack redzone, overridable with -C no-redzone

Rather than hardcoding a specific set of behaviors per-target, with no recourse for escaping them, the compiler would also use this mechanism when deciding how to build for a given target. The process would look like:

  1. Look up the target triple in an internal map, and load that configuration if it exists. If that fails, check if the target name exists as a file, and try loading that. If the file does not exist, look up <target>.json in the RUST_TARGET_PATH, which is a colon-separated list of directories defaulting to /etc/rustc.
  2. If -C linker is specified, use that instead of the target-specified linker.
  3. If -C link-args is given, add those to the ones specified by the target.
  4. If -C target-cpu is specified, replace the target cpu with it.
  5. If -C target-feature is specified, add those to the ones specified by the target.
  6. If -C relocation-model is specified, replace the target relocation-model with it.
  7. If -C code-model is specified, replace the target code-model with it.
  8. If -C no-redzone is specified, replace the target no-redzone with true.

Then during compilation, this information is used at the proper places rather than matching against an enum listing the OSes we recognize. The target_os, target_family, and target_arch cfg variables would be extracted from the --target passed to rustc.

Drawbacks

More complexity. However, this is very flexible and allows one to use Rust on a new or non-standard target incredibly easy, without having to modify the compiler. rustc is the only compiler I know of that would allow that.

Alternatives

A less holistic approach would be to just allow disabling split stacks on a per-crate basis. Another solution could be adding a family of targets, <arch>-unknown-unknown, which omits all of the above complexity but does not allow extending to new targets easily.