Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintain supported sanitizers as a target property #81866

Merged
merged 4 commits into from
Apr 3, 2021

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Feb 7, 2021

In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.

Perhaps the one notable change made in this PR is this doc-comment:

    /// The sanitizers supported by this target
    ///
    /// Note that the support here is at a codegen level. If the machine code with sanitizer
    /// enabled can generated on this target, but the necessary supporting libraries are not
    /// distributed with the target, the sanitizer should still appear in this list for the target. 

Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.

Fixes #81802

@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 7, 2021
@rust-log-analyzer

This comment has been minimized.

@nagisa nagisa force-pushed the nagisa/sanitizer-support-target-prop branch from 09c94a7 to bdee081 Compare February 7, 2021 23:29
@rust-log-analyzer

This comment has been minimized.

@nagisa
Copy link
Member Author

nagisa commented Feb 8, 2021

Hm, this JSON encoding roundtrip test puts some sticks into the wheels :(

@bors
Copy link
Contributor

bors commented Feb 13, 2021

☔ The latest upstream changes (presumably #82045) made this pull request unmergeable. Please resolve the merge conflicts.

@nagisa nagisa force-pushed the nagisa/sanitizer-support-target-prop branch from bdee081 to 1c3740e Compare February 13, 2021 20:00
@nagisa
Copy link
Member Author

nagisa commented Feb 14, 2021

This is good to go now.

Copy link
Contributor

@tmiasko tmiasko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also change the code in link_sanitizer_runtime so that it doesn't match on a targets?

)),
}
// Cannot mix and match sanitizers
// FIXME(nagisa): is there a really good reason that is the case?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All supported sanitizers are pairwise incompatible (we could allow address + leak, but that would be equivalent to address alone, and confusing on targets where leak detection is not enabled by default in ASAN).

@nagisa
Copy link
Member Author

nagisa commented Feb 15, 2021

Could you also change the code in link_sanitizer_runtime so that it doesn't match on a targets?

Aha, I knew I had missed something! Done.

@nagisa nagisa force-pushed the nagisa/sanitizer-support-target-prop branch from f08d194 to 874c67f Compare February 15, 2021 01:20
@crlf0710 crlf0710 added A-sanitizers Area: Sanitizers for correctness and code quality T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 5, 2021
@Dylan-DPC-zz
Copy link

@matthewjasper this is ready for review

@JohnCSimon JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 22, 2021
@bors
Copy link
Contributor

bors commented Mar 25, 2021

☔ The latest upstream changes (presumably #83307) made this pull request unmergeable. Please resolve the merge conflicts.

@nagisa
Copy link
Member Author

nagisa commented Mar 28, 2021

@tmiasko may I consider your checkmark above as an r=tmiasko?

@tmiasko
Copy link
Contributor

tmiasko commented Mar 29, 2021

The changes LGTM, but I don't have approval privileges.

@Dylan-DPC-zz
Copy link

will r+ it after the conflict is resolved

This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.

Fixes rust-lang#81802
@nagisa nagisa force-pushed the nagisa/sanitizer-support-target-prop branch from 874c67f to 41875c8 Compare April 2, 2021 21:38
@nagisa
Copy link
Member Author

nagisa commented Apr 2, 2021

@bors r=tmiasko

Thanks!

@bors
Copy link
Contributor

bors commented Apr 2, 2021

📌 Commit 41875c8 has been approved by tmiasko

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 2, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Apr 2, 2021
…get-prop, r=tmiasko

Maintain supported sanitizers as a target property

In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.

Perhaps the one notable change made in this PR is this doc-comment:

```rust
    /// The sanitizers supported by this target
    ///
    /// Note that the support here is at a codegen level. If the machine code with sanitizer
    /// enabled can generated on this target, but the necessary supporting libraries are not
    /// distributed with the target, the sanitizer should still appear in this list for the target.
```

Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.

Fixes rust-lang#81802
@bors
Copy link
Contributor

bors commented Apr 2, 2021

⌛ Testing commit 41875c8 with merge 9b6c9b6...

@bors
Copy link
Contributor

bors commented Apr 3, 2021

☀️ Test successful - checks-actions
Approved by: tmiasko
Pushing 9b6c9b6 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 3, 2021
@bors bors merged commit 9b6c9b6 into rust-lang:master Apr 3, 2021
@rustbot rustbot added this to the 1.53.0 milestone Apr 3, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 5, 2022
add address sanitizer fo android

We have been being using asan to debug the rust/cpp/c mixed android application in production for months: recompile the rust library with a patched rustc, everything just works fine. The patch is really small thanks to `@nagisa` 's refactoring in rust-lang#81866

r? `@nagisa`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sanitizers Area: Sanitizers for correctness and code quality merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sanitizer support allow-list should not be baked into the compiler (outside of the built-in targets)
10 participants