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

Windows LLVM Sanitizer Support #89339

Closed
voteblake opened this issue Sep 28, 2021 · 3 comments · Fixed by #118521
Closed

Windows LLVM Sanitizer Support #89339

voteblake opened this issue Sep 28, 2021 · 3 comments · Fixed by #118521
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-sanitizers Area: Sanitizers for correctness and code quality O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@voteblake
Copy link

voteblake commented Sep 28, 2021

In an effort to fuzz a Windows-specific Rust program with cargo-fuzz I've done a bit of digging that leads me to think the compiler is the current blocker.

cargo-fuzz mentions libFuzzer "only works on x86-64 Linux and x86-64 macOS for now". The libFuzzer docs in turn suggest Windows should now be support-able, and the LLVM AddressSanitizer documentation appears to agree.

Looking at the history of sanitizer discussion here I see Windows support being mentioned as possible as early as 2017 #39699 (comment). Windows support was also mentioned in #47174 as part of the discussion on stabilizing the -Z sanitize options.

I'm opening this issue to document the data I've gathered, ask for input on if I'm understanding the current state correctly, and also understand if anyone is working on this. I may be able to help, but am not an experienced contributor to the compiler. I've started to work locally to understand what this change would look like if it is in-fact possible.

@voteblake
Copy link
Author

Hi @danielframpton - thanks for tagging this in your PR yesterday, it was great to see that. Very timely! I wanted to invite you to use this issue to track any other outstanding work you're aware of to enable sanitizer support on Windows. If you have any areas you're looking for help or input on I can't guarantee I'd be useful but I'd be happy to try.

@workingjubilee workingjubilee added O-windows-msvc Toolchain: MSVC, Operating system: Windows A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-sanitizers Area: Sanitizers for correctness and code quality labels Sep 30, 2021
@workingjubilee
Copy link
Member

Yes, this seems to be an accurate (partial) description. I am guessing you are mostly speaking about the the MSVC target as the linked document references link.exe arguments?

@voteblake
Copy link
Author

voteblake commented Sep 30, 2021

All the digging I've done is MSVC specific, but the change in #89369 applies codegen changes anywhere is_like_windows not just is_like_msvc. The target spec is only changed for the MSVC target, though.

@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 3, 2024
Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag

This enables address sanitizer for x86_64-pc-windows-msvc and i686-pc-windows-msvc targets when linked with the MSVC linker (link.exe) by leveraging the `/INFERASANLIBS` option to automatically find and link in Microsoft's address sanitizer runtime: <https://learn.microsoft.com/en-us/cpp/sanitizers/asan-runtime?view=msvc-170>

Implements rust-lang/compiler-team#702
Fixes rust-lang#89339 (for MSVC targets using the MSVC linker only)
Supercedes rust-lang#89369

Successful x86_64-msvc build showing the sanitizer tests working: https://github.com/rust-lang/rust/actions/runs/7228346880/job/19697628258?pr=118521
compiler-errors added a commit to compiler-errors/rust that referenced this issue Jan 4, 2024
Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag

This enables address sanitizer for x86_64-pc-windows-msvc and i686-pc-windows-msvc targets when linked with the MSVC linker (link.exe) by leveraging the `/INFERASANLIBS` option to automatically find and link in Microsoft's address sanitizer runtime: <https://learn.microsoft.com/en-us/cpp/sanitizers/asan-runtime?view=msvc-170>

Implements rust-lang/compiler-team#702
Fixes rust-lang#89339 (for MSVC targets using the MSVC linker only)
Supercedes rust-lang#89369

Successful x86_64-msvc build showing the sanitizer tests working: https://github.com/rust-lang/rust/actions/runs/7228346880/job/19697628258?pr=118521
@bors bors closed this as completed in 1f32203 Jan 4, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 4, 2024
Rollup merge of rust-lang#118521 - dpaoliello:asan, r=wesleywiser

Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag

This enables address sanitizer for x86_64-pc-windows-msvc and i686-pc-windows-msvc targets when linked with the MSVC linker (link.exe) by leveraging the `/INFERASANLIBS` option to automatically find and link in Microsoft's address sanitizer runtime: <https://learn.microsoft.com/en-us/cpp/sanitizers/asan-runtime?view=msvc-170>

Implements rust-lang/compiler-team#702
Fixes rust-lang#89339 (for MSVC targets using the MSVC linker only)
Supercedes rust-lang#89369

Successful x86_64-msvc build showing the sanitizer tests working: https://github.com/rust-lang/rust/actions/runs/7228346880/job/19697628258?pr=118521
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-sanitizers Area: Sanitizers for correctness and code quality O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants