sanitizers: Implement support for the sanitize ignorelist - #157808
sanitizers: Implement support for the sanitize ignorelist#1578081c3t3a wants to merge 13 commits into
Conversation
|
Some changes occurred in tests/codegen-llvm/sanitizer cc @rcvalle |
This comment has been minimized.
This comment has been minimized.
624834b to
693e22f
Compare
This comment has been minimized.
This comment has been minimized.
a24ff27 to
eeed708
Compare
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in compiler/rustc_sanitizers cc @rcvalle |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
eeed708 to
066c9e1
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
3f6de90 to
1cb8361
Compare
This comment has been minimized.
This comment has been minimized.
1cb8361 to
a9e36d5
Compare
This comment has been minimized.
This comment has been minimized.
The sanitize ignorelist gives central controls over which functions, files, etc. should be ignored and not sanitized. It is a common file format for clang and explained here: https://clang.llvm.org/docs/SanitizerSpecialCaseList.html. This change adds support for this list in Rust as well.
- Add support for the `[all]` section across all sanitizers. - Restrict CFI ignorelist matching to `[cfi]` and `[cfi-icall]`, ignoring unrelated C++ sub-kinds like `[cfi-vcall]`. - Clean up unused `in_sanitizer_blame` helper. - Add test coverage for `[all]` and `[cfi-icall]`.
In Clang, falling back to [address] for kernel-address (and [hwaddress] for kernel-hwaddress) only applies to global variables, not functions. Update function ignorelist filtering to match Clang.
a9e36d5 to
f071cb7
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
4d27534 to
40db0f2
Compare
This comment has been minimized.
This comment has been minimized.
40db0f2 to
2f2945e
Compare
| /// Opaque type that allows C++ code to write bytes to a Rust-side buffer, | ||
| /// in conjunction with `RawRustStringOstream`. Use this as `&RustString` | ||
| /// (Rust) and `RustStringRef` (C++) in FFI signatures. | ||
| pub(crate) type RustString; |
There was a problem hiding this comment.
Is this actually rustc_llvm::RustString?
I have a remedy, how about abstracting away the interfaces here into a trait and let rustc_llvm provide a trait implementor? A BuilderMethods extension trait might help.
There was a problem hiding this comment.
Makes sense to me! The only problem I see is that cg_llvm is a standalone crate and has no dependencies on other rustc_* crates. Should this then best extend Builder/CodegenCx in cg_ssa?
| } | ||
|
|
||
| impl SanitizerIgnoreList { | ||
| pub fn new(paths: &[String]) -> Result<Self, String> { |
There was a problem hiding this comment.
Yeah, some FFI mechanics could be folded into cg_llvm or so.
There was a problem hiding this comment.
Well, we could move the whole SanitizerIgnoreList there, but Ramon mentioned this could also be tucked away in this crate (which arguably encapsulates it nicer). This is the previous discussion, would be curious what you'd advise!
There was a problem hiding this comment.
@rcvalle: I discussed offline with Xiang, the trait approach here doesn't really make sense, because both the callsite and the impl of the trait would be in cg_llvm. I still like to have this code here, and my understanding is that the rustc_sanitizers crate is anyways llvm centric? Would it makes sense to put this here like this and eventually rename the crate to rustc_llvm_sanitizers? To make sure the tight coupling to cg_llvm? Would be very curious of your opinion :)
View all comments
The sanitize ignorelist gives central controls over which functions, files, etc. should be ignored and not sanitized. It is a common file format for clang and explained here:
https://clang.llvm.org/docs/SanitizerSpecialCaseList.html. This change adds support for this list in Rust as well.
r? @rcvalle