Open
Description
Currently we have:
-
A rustc flag,
-Z sanitizer
, to sanitize rlibs (it adds an extra LLVM pass/attribute) and executables (it links to the sanitizer runtime). Added in LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support #38699. -
An attribute
#[no_sanitize]
to disable sanitization on specific functions. Also lints if those functions are marked as requesting inlining. Added in Selectively disable sanitizer instrumentation #68164.#[no_sanitize]
suppresses#[inline]
hints. A lint is issued if combined with#[inline(always)]
.
-
A few violations (false positives?) in the test runner
- ThreadSanitizer detects a data race in the test runner (
rustc --test
) ThreadSanitizer detects a data race in the test runner (rustc --test
) #39608MemorySanitizer detects an use of unitialized value in the test runner (rustc --test
) MemorySanitizer detects an use of unitialized value in the test runner (rustc --test
) #39610
-
Known issues
- Incremental compilation breaks sanitizers Incremental compilation breaks sanitizers #39611
-
Unresolved questions:
- Should we call the attribute
#[no_sanitize]
or perhaps something like#[sanitize(never)]
or some other variation? In particular, might we at some point want "positive options" like#[sanitize(miri(aggressive))]
? There is much back and forth in Selectively disable sanitizer instrumentation #68164.What should the user experience be to enable sanitizers, particularly when using cargo? Should cargo have first-class support? Is that blocked on build-std stabilizing?
Metadata
Metadata
Assignees
Labels
Area: Command-line interface (CLI) to the compilerArea: Sanitizers for correctness and code qualityBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
kennytm commentedon Apr 27, 2017
Just for record. Currently only 4 sanitizers are enabled (asan, lsan, msan, tsan), and only in
x86_64-unknown-linux-gnu
(#38699) andx86_64-apple-darwin
(#41352).As of the LLVM 4.0 merge (rust-lang/compiler-rt@c8a8767c5), compiler-rt actually supports much more targets than rustc do, and also some additional sanitizers (e.g. esan) can be enabled in the future.
(not all of these are sanitizers, some of them are just tools or libraries that depend on the common sanitizer runtime)
cuviper commentedon May 5, 2017
Is there any plan for stabilization here? Even if it remains x86_64-only for now, with only a few of the available sanitizers, it will still be quite useful to have. I have users that want this (rhbz1447423), but now that -Z is forbidden I want to wait for properly-supported sanitizer options.
Firstyear commentedon May 9, 2017
Hi,
If I understand this issue, you would like to block certain -Z features from coming to stable rust. Sanitisers seems to be one of these. We have a very good use case for them though. When you have a C + Rust with FFI, and the C code is linked to libasan, the rust component will fail to link as it's missing libasan. For us it's important to get sanitisers into rust stable as we have an extensive C code based (that is well sanitised), and having this option available to us will help to determine if our Rust + C integration is behaving correctly.
I hope this helps explain our use case, as for us this is a blocker to our project adopting Rust today.
Thanks you!
cuviper commentedon May 9, 2017
FWIW, it's not just certain -Z features, but -Z as a whole being blocked as unstable now.
Firstyear commentedon Jun 17, 2017
#42711 PR for dylib asan support.
94 remaining items