-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
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. |
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 |
All the digging I've done is MSVC specific, but the change in #89369 applies codegen changes anywhere |
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
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
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
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
mentionslibFuzzer
"only works on x86-64 Linux and x86-64 macOS for now". ThelibFuzzer
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.
The text was updated successfully, but these errors were encountered: