rust/compiler/rustc_interface/src/tests.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

825 lines
29 KiB
Rust
Raw Normal View History

2019-10-11 16:48:16 -05:00
use crate::interface::parse_cfgspecs;
use rustc_data_structures::fx::FxHashSet;
2019-10-11 16:48:16 -05:00
use rustc_errors::{emitter::HumanReadableErrorType, registry, ColorConfig};
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports.
2021-03-15 18:32:45 -05:00
use rustc_session::config::InstrumentCoverage;
use rustc_session::config::Strip;
use rustc_session::config::{build_configuration, build_session_options, to_crate_config};
2021-10-15 10:58:28 -05:00
use rustc_session::config::{
rustc_optgroups, ErrorOutputType, ExternLocation, LocationDetail, Options, Passes,
};
use rustc_session::config::{
BranchProtection, Externs, OomStrategy, OutputType, OutputTypes, PAuthKey, PacRet,
SymbolManglingVersion, WasiExecModel,
};
use rustc_session::config::{CFGuard, ExternEntry, LinkerPluginLto, LtoCli, SwitchWithOptPath};
use rustc_session::lint::Level;
use rustc_session::search_paths::SearchPath;
use rustc_session::utils::{CanonicalizedPath, NativeLib, NativeLibKind};
use rustc_session::{build_session, getopts, DiagnosticOutput, Session};
2020-01-01 12:40:49 -06:00
use rustc_span::edition::{Edition, DEFAULT_EDITION};
2020-01-01 12:30:57 -06:00
use rustc_span::symbol::sym;
2020-04-20 22:25:07 -05:00
use rustc_span::SourceFileHashAlgorithm;
use rustc_target::spec::{CodeModel, LinkerFlavor, MergeFunctions, PanicStrategy};
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
use rustc_target::spec::{
RelocModel, RelroLevel, SanitizerSet, SplitDebuginfo, StackProtector, TlsModel,
};
2019-06-05 13:16:41 -05:00
use std::collections::{BTreeMap, BTreeSet};
use std::iter::FromIterator;
use std::num::NonZeroUsize;
use std::path::{Path, PathBuf};
2019-10-10 03:26:10 -05:00
type CfgSpecs = FxHashSet<(String, Option<String>)>;
fn build_session_options_and_crate_config(matches: getopts::Matches) -> (Options, CfgSpecs) {
let sessopts = build_session_options(&matches);
let cfg = parse_cfgspecs(matches.opt_strs("cfg"));
(sessopts, cfg)
}
fn mk_session(matches: getopts::Matches) -> (Session, CfgSpecs) {
let registry = registry::Registry::new(&[]);
let (sessopts, cfg) = build_session_options_and_crate_config(matches);
let sess = build_session(
sessopts,
None,
None,
registry,
DiagnosticOutput::Default,
Default::default(),
None,
None,
);
2019-10-10 03:26:10 -05:00
(sess, cfg)
}
2019-06-05 13:16:41 -05:00
2019-10-11 16:48:16 -05:00
fn new_public_extern_entry<S, I>(locations: I) -> ExternEntry
where
S: Into<String>,
2019-12-05 16:43:53 -06:00
I: IntoIterator<Item = S>,
2019-10-11 16:48:16 -05:00
{
let locations: BTreeSet<CanonicalizedPath> =
locations.into_iter().map(|s| CanonicalizedPath::new(Path::new(&s.into()))).collect();
2019-10-11 16:48:16 -05:00
ExternEntry {
2019-12-05 16:43:53 -06:00
location: ExternLocation::ExactPaths(locations),
is_private_dep: false,
add_prelude: true,
nounused_dep: false,
2019-06-05 13:16:41 -05:00
}
}
fn optgroups() -> getopts::Options {
let mut opts = getopts::Options::new();
2019-10-11 16:48:16 -05:00
for group in rustc_optgroups() {
2019-06-05 13:16:41 -05:00
(group.apply)(&mut opts);
}
return opts;
}
fn mk_map<K: Ord, V>(entries: Vec<(K, V)>) -> BTreeMap<K, V> {
BTreeMap::from_iter(entries.into_iter())
}
fn assert_same_clone(x: &Options) {
assert_eq!(x.dep_tracking_hash(true), x.clone().dep_tracking_hash(true));
assert_eq!(x.dep_tracking_hash(false), x.clone().dep_tracking_hash(false));
}
fn assert_same_hash(x: &Options, y: &Options) {
assert_eq!(x.dep_tracking_hash(true), y.dep_tracking_hash(true));
assert_eq!(x.dep_tracking_hash(false), y.dep_tracking_hash(false));
// Check clone
assert_same_clone(x);
assert_same_clone(y);
}
fn assert_different_hash(x: &Options, y: &Options) {
assert_ne!(x.dep_tracking_hash(true), y.dep_tracking_hash(true));
assert_ne!(x.dep_tracking_hash(false), y.dep_tracking_hash(false));
// Check clone
assert_same_clone(x);
assert_same_clone(y);
}
fn assert_non_crate_hash_different(x: &Options, y: &Options) {
assert_eq!(x.dep_tracking_hash(true), y.dep_tracking_hash(true));
assert_ne!(x.dep_tracking_hash(false), y.dep_tracking_hash(false));
// Check clone
assert_same_clone(x);
assert_same_clone(y);
}
2019-06-05 13:16:41 -05:00
// When the user supplies --test we should implicitly supply --cfg test
#[test]
fn test_switch_implies_cfg_test() {
rustc_span::create_default_session_globals_then(|| {
2019-10-10 03:26:10 -05:00
let matches = optgroups().parse(&["--test".to_string()]).unwrap();
let (sess, cfg) = mk_session(matches);
2019-06-05 13:16:41 -05:00
let cfg = build_configuration(&sess, to_crate_config(cfg));
assert!(cfg.contains(&(sym::test, None)));
});
}
2019-10-10 03:26:10 -05:00
// When the user supplies --test and --cfg test, don't implicitly add another --cfg test
2019-06-05 13:16:41 -05:00
#[test]
fn test_switch_implies_cfg_test_unless_cfg_test() {
rustc_span::create_default_session_globals_then(|| {
2019-10-10 03:26:10 -05:00
let matches = optgroups().parse(&["--test".to_string(), "--cfg=test".to_string()]).unwrap();
let (sess, cfg) = mk_session(matches);
2019-06-05 13:16:41 -05:00
let cfg = build_configuration(&sess, to_crate_config(cfg));
let mut test_items = cfg.iter().filter(|&&(name, _)| name == sym::test);
assert!(test_items.next().is_some());
assert!(test_items.next().is_none());
});
}
#[test]
fn test_can_print_warnings() {
rustc_span::create_default_session_globals_then(|| {
2019-06-05 13:16:41 -05:00
let matches = optgroups().parse(&["-Awarnings".to_string()]).unwrap();
2019-10-10 03:26:10 -05:00
let (sess, _) = mk_session(matches);
assert!(!sess.diagnostic().can_emit_warnings());
2019-06-05 13:16:41 -05:00
});
rustc_span::create_default_session_globals_then(|| {
2019-06-05 13:16:41 -05:00
let matches =
optgroups().parse(&["-Awarnings".to_string(), "-Dwarnings".to_string()]).unwrap();
2019-10-10 03:26:10 -05:00
let (sess, _) = mk_session(matches);
assert!(sess.diagnostic().can_emit_warnings());
2019-06-05 13:16:41 -05:00
});
rustc_span::create_default_session_globals_then(|| {
2019-06-05 13:16:41 -05:00
let matches = optgroups().parse(&["-Adead_code".to_string()]).unwrap();
2019-10-10 03:26:10 -05:00
let (sess, _) = mk_session(matches);
assert!(sess.diagnostic().can_emit_warnings());
2019-06-05 13:16:41 -05:00
});
}
#[test]
fn test_output_types_tracking_hash_different_paths() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
v1.output_types = OutputTypes::new(&[(OutputType::Exe, Some(PathBuf::from("./some/thing")))]);
v2.output_types = OutputTypes::new(&[(OutputType::Exe, Some(PathBuf::from("/some/thing")))]);
v3.output_types = OutputTypes::new(&[(OutputType::Exe, None)]);
assert_non_crate_hash_different(&v1, &v2);
assert_non_crate_hash_different(&v1, &v3);
assert_non_crate_hash_different(&v2, &v3);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_output_types_tracking_hash_different_construction_order() {
let mut v1 = Options::default();
let mut v2 = Options::default();
v1.output_types = OutputTypes::new(&[
(OutputType::Exe, Some(PathBuf::from("./some/thing"))),
(OutputType::Bitcode, Some(PathBuf::from("./some/thing.bc"))),
]);
v2.output_types = OutputTypes::new(&[
(OutputType::Bitcode, Some(PathBuf::from("./some/thing.bc"))),
(OutputType::Exe, Some(PathBuf::from("./some/thing"))),
]);
assert_same_hash(&v1, &v2);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_externs_tracking_hash_different_construction_order() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
v1.externs = Externs::new(mk_map(vec![
2019-12-05 16:43:53 -06:00
(String::from("a"), new_public_extern_entry(vec!["b", "c"])),
(String::from("d"), new_public_extern_entry(vec!["e", "f"])),
2019-06-05 13:16:41 -05:00
]));
v2.externs = Externs::new(mk_map(vec![
2019-12-05 16:43:53 -06:00
(String::from("d"), new_public_extern_entry(vec!["e", "f"])),
(String::from("a"), new_public_extern_entry(vec!["b", "c"])),
2019-06-05 13:16:41 -05:00
]));
v3.externs = Externs::new(mk_map(vec![
2019-12-05 16:43:53 -06:00
(String::from("a"), new_public_extern_entry(vec!["b", "c"])),
(String::from("d"), new_public_extern_entry(vec!["f", "e"])),
2019-06-05 13:16:41 -05:00
]));
assert_same_hash(&v1, &v2);
assert_same_hash(&v1, &v3);
assert_same_hash(&v2, &v3);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_lints_tracking_hash_different_values() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
v1.lint_opts = vec![
2020-01-09 23:53:07 -06:00
(String::from("a"), Level::Allow),
(String::from("b"), Level::Warn),
(String::from("c"), Level::Deny),
(String::from("d"), Level::Forbid),
2019-06-05 13:16:41 -05:00
];
v2.lint_opts = vec![
2020-01-09 23:53:07 -06:00
(String::from("a"), Level::Allow),
(String::from("b"), Level::Warn),
(String::from("X"), Level::Deny),
(String::from("d"), Level::Forbid),
2019-06-05 13:16:41 -05:00
];
v3.lint_opts = vec![
2020-01-09 23:53:07 -06:00
(String::from("a"), Level::Allow),
(String::from("b"), Level::Warn),
(String::from("c"), Level::Forbid),
(String::from("d"), Level::Deny),
2019-06-05 13:16:41 -05:00
];
assert_non_crate_hash_different(&v1, &v2);
assert_non_crate_hash_different(&v1, &v3);
assert_non_crate_hash_different(&v2, &v3);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_lints_tracking_hash_different_construction_order() {
let mut v1 = Options::default();
let mut v2 = Options::default();
v1.lint_opts = vec![
2020-01-09 23:53:07 -06:00
(String::from("a"), Level::Allow),
(String::from("b"), Level::Warn),
(String::from("c"), Level::Deny),
(String::from("d"), Level::Forbid),
2019-06-05 13:16:41 -05:00
];
v2.lint_opts = vec![
2020-01-09 23:53:07 -06:00
(String::from("a"), Level::Allow),
(String::from("c"), Level::Deny),
(String::from("b"), Level::Warn),
(String::from("d"), Level::Forbid),
2019-06-05 13:16:41 -05:00
];
// The hash should be order-dependent
assert_non_crate_hash_different(&v1, &v2);
}
#[test]
fn test_lint_cap_hash_different() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let v3 = Options::default();
v1.lint_cap = Some(Level::Forbid);
v2.lint_cap = Some(Level::Allow);
assert_non_crate_hash_different(&v1, &v2);
assert_non_crate_hash_different(&v1, &v3);
assert_non_crate_hash_different(&v2, &v3);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_search_paths_tracking_hash_different_order() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
let mut v4 = Options::default();
2019-10-11 16:48:16 -05:00
const JSON: ErrorOutputType = ErrorOutputType::Json {
2019-06-05 13:16:41 -05:00
pretty: false,
2019-10-11 16:48:16 -05:00
json_rendered: HumanReadableErrorType::Default(ColorConfig::Never),
2019-06-05 13:16:41 -05:00
};
// Reference
v1.search_paths.push(SearchPath::from_cli_opt("native=abc", JSON));
v1.search_paths.push(SearchPath::from_cli_opt("crate=def", JSON));
v1.search_paths.push(SearchPath::from_cli_opt("dependency=ghi", JSON));
v1.search_paths.push(SearchPath::from_cli_opt("framework=jkl", JSON));
v1.search_paths.push(SearchPath::from_cli_opt("all=mno", JSON));
2019-12-22 16:42:04 -06:00
2019-06-05 13:16:41 -05:00
v2.search_paths.push(SearchPath::from_cli_opt("native=abc", JSON));
v2.search_paths.push(SearchPath::from_cli_opt("dependency=ghi", JSON));
v2.search_paths.push(SearchPath::from_cli_opt("crate=def", JSON));
v2.search_paths.push(SearchPath::from_cli_opt("framework=jkl", JSON));
v2.search_paths.push(SearchPath::from_cli_opt("all=mno", JSON));
2019-12-22 16:42:04 -06:00
2019-06-05 13:16:41 -05:00
v3.search_paths.push(SearchPath::from_cli_opt("crate=def", JSON));
v3.search_paths.push(SearchPath::from_cli_opt("framework=jkl", JSON));
v3.search_paths.push(SearchPath::from_cli_opt("native=abc", JSON));
v3.search_paths.push(SearchPath::from_cli_opt("dependency=ghi", JSON));
v3.search_paths.push(SearchPath::from_cli_opt("all=mno", JSON));
2019-12-22 16:42:04 -06:00
2019-06-05 13:16:41 -05:00
v4.search_paths.push(SearchPath::from_cli_opt("all=mno", JSON));
v4.search_paths.push(SearchPath::from_cli_opt("native=abc", JSON));
v4.search_paths.push(SearchPath::from_cli_opt("crate=def", JSON));
v4.search_paths.push(SearchPath::from_cli_opt("dependency=ghi", JSON));
v4.search_paths.push(SearchPath::from_cli_opt("framework=jkl", JSON));
assert_same_hash(&v1, &v2);
assert_same_hash(&v1, &v3);
assert_same_hash(&v1, &v4);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_native_libs_tracking_hash_different_values() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
let mut v4 = Options::default();
let mut v5 = Options::default();
2019-06-05 13:16:41 -05:00
// Reference
v1.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
// Change label
v2.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("X"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
// Change kind
v3.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
// Change new-name
v4.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: Some(String::from("X")),
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
];
// Change verbatim
v5.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: Some(true),
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
assert_different_hash(&v1, &v2);
assert_different_hash(&v1, &v3);
assert_different_hash(&v1, &v4);
assert_different_hash(&v1, &v5);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_native_libs_tracking_hash_different_order() {
let mut v1 = Options::default();
let mut v2 = Options::default();
let mut v3 = Options::default();
// Reference
v1.libs = vec![
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
v2.libs = vec![
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
v3.libs = vec![
NativeLib {
name: String::from("c"),
new_name: None,
kind: NativeLibKind::Unspecified,
verbatim: None,
},
NativeLib {
name: String::from("a"),
new_name: None,
kind: NativeLibKind::Static { bundle: None, whole_archive: None },
verbatim: None,
},
NativeLib {
name: String::from("b"),
new_name: None,
kind: NativeLibKind::Framework { as_needed: None },
verbatim: None,
},
2019-06-05 13:16:41 -05:00
];
// The hash should be order-dependent
assert_different_hash(&v1, &v2);
assert_different_hash(&v1, &v3);
assert_different_hash(&v2, &v3);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_codegen_options_tracking_hash() {
let reference = Options::default();
let mut opts = Options::default();
2020-04-21 00:55:02 -05:00
macro_rules! untracked {
($name: ident, $non_default_value: expr) => {
assert_ne!(opts.cg.$name, $non_default_value);
2020-04-21 00:55:02 -05:00
opts.cg.$name = $non_default_value;
assert_same_hash(&reference, &opts);
2020-04-21 00:55:02 -05:00
};
}
// Make sure that changing an [UNTRACKED] option leaves the hash unchanged.
// This list is in alphabetical order.
2020-04-21 00:55:02 -05:00
untracked!(ar, String::from("abc"));
untracked!(codegen_units, Some(42));
untracked!(default_linker_libraries, true);
untracked!(extra_filename, String::from("extra-filename"));
untracked!(incremental, Some(String::from("abc")));
2020-04-20 22:25:07 -05:00
// `link_arg` is omitted because it just forwards to `link_args`.
2020-04-21 00:55:02 -05:00
untracked!(link_args, vec![String::from("abc"), String::from("def")]);
2020-07-30 15:10:48 -05:00
untracked!(link_self_contained, Some(true));
2020-04-21 00:55:02 -05:00
untracked!(linker, Some(PathBuf::from("linker")));
untracked!(linker_flavor, Some(LinkerFlavor::Gcc));
untracked!(no_stack_check, true);
untracked!(remark, Passes::Some(vec![String::from("pass1"), String::from("pass2")]));
untracked!(rpath, true);
untracked!(save_temps, true);
untracked!(strip, Strip::Debuginfo);
2020-04-21 00:55:02 -05:00
macro_rules! tracked {
($name: ident, $non_default_value: expr) => {
opts = reference.clone();
assert_ne!(opts.cg.$name, $non_default_value);
2020-04-21 00:55:02 -05:00
opts.cg.$name = $non_default_value;
assert_different_hash(&reference, &opts);
2020-04-21 00:55:02 -05:00
};
}
2019-06-05 13:16:41 -05:00
// Make sure that changing a [TRACKED] option changes the hash.
// This list is in alphabetical order.
tracked!(code_model, Some(CodeModel::Large));
tracked!(control_flow_guard, CFGuard::Checks);
2020-04-21 00:55:02 -05:00
tracked!(debug_assertions, Some(true));
tracked!(debuginfo, 0xdeadbeef);
tracked!(embed_bitcode, false);
2020-04-21 00:55:02 -05:00
tracked!(force_frame_pointers, Some(false));
tracked!(force_unwind_tables, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(inline_threshold, Some(0xf007ba11));
tracked!(instrument_coverage, Some(InstrumentCoverage::All));
2020-04-21 00:55:02 -05:00
tracked!(linker_plugin_lto, LinkerPluginLto::LinkerPluginAuto);
tracked!(link_dead_code, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(llvm_args, vec![String::from("1"), String::from("2")]);
tracked!(lto, LtoCli::Fat);
tracked!(metadata, vec![String::from("A"), String::from("B")]);
tracked!(no_prepopulate_passes, true);
tracked!(no_redzone, Some(true));
tracked!(no_vectorize_loops, true);
tracked!(no_vectorize_slp, true);
tracked!(opt_level, "3".to_string());
tracked!(overflow_checks, Some(true));
tracked!(panic, Some(PanicStrategy::Abort));
tracked!(passes, vec![String::from("1"), String::from("2")]);
tracked!(prefer_dynamic, true);
tracked!(profile_generate, SwitchWithOptPath::Enabled(None));
tracked!(profile_use, Some(PathBuf::from("abc")));
tracked!(relocation_model, Some(RelocModel::Pic));
2020-04-21 00:55:02 -05:00
tracked!(soft_float, true);
rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc, `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files, meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361, but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default, but that's a problem left to get tackled another day. Closes #79361
2020-11-30 10:39:08 -06:00
tracked!(split_debuginfo, Some(SplitDebuginfo::Packed));
tracked!(symbol_mangling_version, Some(SymbolManglingVersion::V0));
2020-04-21 00:55:02 -05:00
tracked!(target_cpu, Some(String::from("abc")));
tracked!(target_feature, String::from("all the features, all of them"));
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_top_level_options_tracked_no_crate() {
let reference = Options::default();
let mut opts;
macro_rules! tracked {
($name: ident, $non_default_value: expr) => {
opts = reference.clone();
assert_ne!(opts.$name, $non_default_value);
opts.$name = $non_default_value;
// The crate hash should be the same
assert_eq!(reference.dep_tracking_hash(true), opts.dep_tracking_hash(true));
// The incremental hash should be different
assert_ne!(reference.dep_tracking_hash(false), opts.dep_tracking_hash(false));
};
}
// Make sure that changing a [TRACKED_NO_CRATE_HASH] option leaves the crate hash unchanged but changes the incremental hash.
// This list is in alphabetical order.
tracked!(remap_path_prefix, vec![("/home/bors/rust".into(), "src".into())]);
tracked!(
real_rust_source_base_dir,
Some("/home/bors/rust/.rustup/toolchains/nightly/lib/rustlib/src/rust".into())
);
}
2019-06-05 13:16:41 -05:00
#[test]
fn test_debugging_options_tracking_hash() {
let reference = Options::default();
let mut opts = Options::default();
2020-04-21 00:55:02 -05:00
macro_rules! untracked {
($name: ident, $non_default_value: expr) => {
assert_ne!(opts.debugging_opts.$name, $non_default_value);
2020-04-21 00:55:02 -05:00
opts.debugging_opts.$name = $non_default_value;
assert_same_hash(&reference, &opts);
2020-04-21 00:55:02 -05:00
};
}
// Make sure that changing an [UNTRACKED] option leaves the hash unchanged.
// This list is in alphabetical order.
untracked!(assert_incr_state, Some(String::from("loaded")));
2020-04-21 00:55:02 -05:00
untracked!(ast_json, true);
untracked!(ast_json_noexpand, true);
untracked!(borrowck, String::from("other"));
untracked!(deduplicate_diagnostics, false);
2020-04-21 00:55:02 -05:00
untracked!(dep_tasks, true);
untracked!(dlltool, Some(PathBuf::from("custom_dlltool.exe")));
2020-04-21 00:55:02 -05:00
untracked!(dont_buffer_diagnostics, true);
untracked!(dump_dep_graph, true);
untracked!(dump_mir, Some(String::from("abc")));
untracked!(dump_mir_dataflow, true);
untracked!(dump_mir_dir, String::from("abc"));
untracked!(dump_mir_exclude_pass_number, true);
untracked!(dump_mir_graphviz, true);
untracked!(emit_stack_sizes, true);
untracked!(future_incompat_test, true);
2020-04-21 00:55:02 -05:00
untracked!(hir_stats, true);
untracked!(identify_regions, true);
untracked!(incremental_ignore_spans, true);
untracked!(incremental_info, true);
untracked!(incremental_verify_ich, true);
untracked!(input_stats, true);
untracked!(keep_hygiene_data, true);
untracked!(link_native_libraries, false);
untracked!(llvm_time_trace, true);
untracked!(ls, true);
untracked!(macro_backtrace, true);
untracked!(meta_stats, true);
untracked!(nll_facts, true);
untracked!(no_analysis, true);
untracked!(no_interleave_lints, true);
untracked!(no_leak_check, true);
untracked!(no_parallel_llvm, true);
untracked!(parse_only, true);
untracked!(perf_stats, true);
2020-04-20 22:25:07 -05:00
// `pre_link_arg` is omitted because it just forwards to `pre_link_args`.
2020-04-21 00:55:02 -05:00
untracked!(pre_link_args, vec![String::from("abc"), String::from("def")]);
untracked!(profile_closures, true);
2020-04-21 00:55:02 -05:00
untracked!(print_llvm_passes, true);
untracked!(print_mono_items, Some(String::from("abc")));
untracked!(print_type_sizes, true);
untracked!(proc_macro_backtrace, true);
2020-04-21 00:55:02 -05:00
untracked!(query_dep_graph, true);
untracked!(save_analysis, true);
untracked!(self_profile, SwitchWithOptPath::Enabled(None));
untracked!(self_profile_events, Some(vec![String::new()]));
untracked!(span_debug, true);
2020-04-21 00:55:02 -05:00
untracked!(span_free_formats, true);
2021-11-06 18:14:54 -05:00
untracked!(temps_dir, Some(String::from("abc")));
2020-04-21 00:55:02 -05:00
untracked!(terminal_width, Some(80));
untracked!(threads, 99);
untracked!(time, true);
untracked!(time_llvm_passes, true);
untracked!(time_passes, true);
untracked!(trace_macros, true);
untracked!(trim_diagnostic_paths, false);
2020-04-21 00:55:02 -05:00
untracked!(ui_testing, true);
untracked!(unpretty, Some("expanded".to_string()));
untracked!(unstable_options, true);
2020-05-23 17:55:44 -05:00
untracked!(validate_mir, true);
2020-04-21 00:55:02 -05:00
untracked!(verbose, true);
macro_rules! tracked {
($name: ident, $non_default_value: expr) => {
opts = reference.clone();
assert_ne!(opts.debugging_opts.$name, $non_default_value);
2020-04-21 00:55:02 -05:00
opts.debugging_opts.$name = $non_default_value;
assert_different_hash(&reference, &opts);
2020-04-21 00:55:02 -05:00
};
}
2019-06-05 13:16:41 -05:00
// Make sure that changing a [TRACKED] option changes the hash.
// This list is in alphabetical order.
2020-04-21 00:55:02 -05:00
tracked!(allow_features, Some(vec![String::from("lang_items")]));
tracked!(always_encode_mir, true);
tracked!(asm_comments, true);
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
tracked!(assume_incomplete_release, true);
2020-04-21 00:55:02 -05:00
tracked!(binary_dep_depinfo, true);
tracked!(
branch_protection,
Some(BranchProtection {
bti: true,
pac_ret: Some(PacRet { leaf: true, key: PAuthKey::B })
})
);
2020-03-03 10:25:03 -06:00
tracked!(chalk, true);
2020-04-21 00:55:02 -05:00
tracked!(codegen_backend, Some("abc".to_string()));
tracked!(crate_attr, vec!["abc".to_string()]);
tracked!(debug_info_for_profiling, true);
2020-04-21 00:55:02 -05:00
tracked!(debug_macros, true);
tracked!(dep_info_omit_d_target, true);
tracked!(drop_tracking, true);
2020-04-21 00:55:02 -05:00
tracked!(dual_proc_macros, true);
tracked!(fewer_names, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(force_unstable_if_unmarked, true);
tracked!(fuel, Some(("abc".to_string(), 99)));
tracked!(function_sections, Some(false));
2020-04-21 00:55:02 -05:00
tracked!(human_readable_cgu_names, true);
tracked!(inline_in_all_cgus, Some(true));
tracked!(inline_mir, Some(true));
tracked!(inline_mir_hint_threshold, Some(123));
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
tracked!(inline_mir_threshold, Some(123));
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports.
2021-03-15 18:32:45 -05:00
tracked!(instrument_coverage, Some(InstrumentCoverage::All));
2020-04-21 00:55:02 -05:00
tracked!(instrument_mcount, true);
tracked!(link_only, true);
tracked!(llvm_plugins, vec![String::from("plugin_name")]);
2021-10-15 10:58:28 -05:00
tracked!(location_detail, LocationDetail { file: true, line: false, column: false });
2020-04-21 00:55:02 -05:00
tracked!(merge_functions, Some(MergeFunctions::Disabled));
tracked!(mir_emit_retag, true);
2022-04-11 14:17:52 -05:00
tracked!(mir_enable_passes, vec![("DestProp".to_string(), false)]);
tracked!(mir_opt_level, Some(4));
tracked!(move_size_limit, Some(4096));
tracked!(mutable_noalias, Some(true));
tracked!(new_llvm_pass_manager, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(no_generate_arange_section, true);
tracked!(no_link, true);
tracked!(no_unique_section_names, true);
tracked!(no_profiler_runtime, true);
tracked!(oom, OomStrategy::Panic);
2020-04-21 00:55:02 -05:00
tracked!(osx_rpath_install_name, true);
tracked!(panic_abort_tests, true);
tracked!(panic_in_drop, PanicStrategy::Abort);
tracked!(pick_stable_methods_before_any_unstable, false);
2020-04-21 00:55:02 -05:00
tracked!(plt, Some(true));
2020-11-24 20:58:20 -06:00
tracked!(polonius, true);
tracked!(precise_enum_drop_elaboration, false);
2020-04-21 00:55:02 -05:00
tracked!(print_fuel, Some("abc".to_string()));
tracked!(profile, true);
tracked!(profile_emit, Some(PathBuf::from("abc")));
tracked!(profiler_runtime, "abc".to_string());
tracked!(profile_sample_use, Some(PathBuf::from("abc")));
tracked!(relax_elf_relocations, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(relro_level, Some(RelroLevel::Full));
2021-07-22 13:52:45 -05:00
tracked!(remap_cwd_prefix, Some(PathBuf::from("abc")));
2020-04-21 00:55:02 -05:00
tracked!(report_delayed_bugs, true);
tracked!(sanitizer, SanitizerSet::ADDRESS);
2020-04-21 00:55:02 -05:00
tracked!(sanitizer_memory_track_origins, 2);
tracked!(sanitizer_recover, SanitizerSet::ADDRESS);
tracked!(saturating_float_casts, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(share_generics, Some(true));
tracked!(show_span, Some(String::from("abc")));
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
tracked!(simulate_remapped_rust_src_base, Some(PathBuf::from("/rustc/abc")));
2020-04-21 00:55:02 -05:00
tracked!(src_hash_algorithm, Some(SourceFileHashAlgorithm::Sha1));
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
tracked!(stack_protector, StackProtector::All);
tracked!(symbol_mangling_version, Some(SymbolManglingVersion::V0));
2020-04-21 00:55:02 -05:00
tracked!(teach, true);
tracked!(thinlto, Some(true));
tracked!(thir_unsafeck, true);
tracked!(tls_model, Some(TlsModel::GeneralDynamic));
tracked!(trap_unreachable, Some(false));
tracked!(treat_err_as_bug, NonZeroUsize::new(1));
add rustc option for using LLVM stack smash protection LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-04-06 14:37:49 -05:00
tracked!(tune_cpu, Some(String::from("abc")));
tracked!(uninit_const_chunk_threshold, 123);
2020-04-21 00:55:02 -05:00
tracked!(unleash_the_miri_inside_of_you, true);
tracked!(use_ctors_section, Some(true));
2020-04-21 00:55:02 -05:00
tracked!(verify_llvm_ir, true);
tracked!(wasi_exec_model, Some(WasiExecModel::Reactor));
macro_rules! tracked_no_crate_hash {
($name: ident, $non_default_value: expr) => {
opts = reference.clone();
assert_ne!(opts.debugging_opts.$name, $non_default_value);
opts.debugging_opts.$name = $non_default_value;
assert_non_crate_hash_different(&reference, &opts);
};
}
tracked_no_crate_hash!(no_codegen, true);
2019-06-05 13:16:41 -05:00
}
#[test]
fn test_edition_parsing() {
// test default edition
let options = Options::default();
assert!(options.edition == DEFAULT_EDITION);
let matches = optgroups().parse(&["--edition=2018".to_string()]).unwrap();
2019-10-10 03:26:10 -05:00
let (sessopts, _) = build_session_options_and_crate_config(matches);
2019-06-05 13:16:41 -05:00
assert!(sessopts.edition == Edition::Edition2018)
}