Note: This RFC discusses the behavior of
rustc, and not any changes to the
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.
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.
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
features: Default target features to enable, augmentable with
dynamic-linking-available: Whether the
dylibcrate 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_word_size: Specify the strings used for the corresponding
code-model: Code model to pass to LLVM, overridable with
no-redzone: Disable use of any stack redzone, overridable with
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:
- 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
RUST_TARGET_PATH, which is a colon-separated list of directories.
-C linkeris specified, use that instead of the target-specified linker.
-C link-argsis given, add those to the ones specified by the target.
-C target-cpuis specified, replace the target
-C target-featureis specified, add those to the ones specified by the target.
-C relocation-modelis specified, replace the target
-C code-modelis specified, replace the target
-C no-redzoneis specified, replace the target
Then during compilation, this information is used at the proper places rather
than matching against an enum listing the OSes we recognize. The
cfg variables would be extracted from the
--target passed to rustc.
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.
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.