[scudo] Allow -fsanitize=scudo on Linux and Windows (WIP, don't land as is)

[russell.gallop]

Summary

This is basically https://reviews.llvm.org/D42519 updated for monorepo and support for scudo on -DLLVM_INTEGRATED_CRT_ALLOC.

This is to allow evaluation of Scudo as a replacement memory allocator on Windows for comparison with https://reviews.llvm.org/D71786

[cryptoad]

That's awesome! Is it meant to eventually be committed or only be used for comparison purposes?

[russell.gallop]

In D86694#2242140, @cryptoad wrote:

That's awesome! Is it meant to eventually be committed or only be used for comparison purposes?

I'd like it to be committed, but can't claim I know the code from https://reviews.llvm.org/D42519 well enough. The good news is that I can build LLVM on Windows with this. Is there a good sanity check that it is actually using Scudo rather than silently using the standard alloc?

You marked D42519 as WIP, can you remember what was still TBD?

Also, it might make sense to separate out the "use" of sanitize=Scudo in LLVM, from providing Windows support. I put them together here for evaluation purposes.

[russell.gallop]

In D86694#2242150, @russell.gallop wrote:

You marked D42519 as WIP, can you remember what was still TBD?

Maybe more tests could be enabled...

[cryptoad]

In D86694#2242150, @russell.gallop wrote:

In D86694#2242140, @cryptoad wrote:

That's awesome! Is it meant to eventually be committed or only be used for comparison purposes?

I'd like it to be committed, but can't claim I know the code from https://reviews.llvm.org/D42519 well enough. The good news is that I can build LLVM on Windows with this. Is there a good sanity check that it is actually using Scudo rather than silently using the standard alloc?

Nothing except the tests. Compiling a sizeable application with Scudo as well.

You marked D42519 as WIP, can you remember what was still TBD?

Mostly because I didn't have the time and resources to make sure this would work over the long term.
I used my home windows box to do this as a proof of concept that it could be done.

Also, it might make sense to separate out the "use" of sanitize=Scudo in LLVM, from providing Windows support. I put them together here for evaluation purposes.

Yeah this makes sense.

The other point that is worth mentioning is that we moved all dev efforts to the "standalone" version of Scudo (eg: the one not depending on sanitizer_common in the standalone/ subdirectory).
There is enough differences that there could be some significant performance/mem footprint changes between the 2.

Also depending on what you want to compare, disabling the Quarantine and other optional security features will make things faster and use less memory.

[russell.gallop]

Fixup scudo (sanitizer based) to work on Windows.

This makes use of the CRT alloc hooks from D71786.

To build with scudo on Windows use: -DLLVM_INTEGRATED_CRT_ALLOC=<llvm-project>/stage1/lib/clang/12.0.0/lib/windows/clang_rt.scudo-x86_64.lib -DLLVM_USE_CRT_RELEASE=MT
-DLLVM_USE_SANITIZER=Scudo is supported in this patch, but isn't required. @cryptoad on Linux does this do anything other than add libraries when using clang to drive the linker?

Limitations:
-Note that this is not using hardware CRC32.
-This just hooks in the C scudo library, not the cxx library

I evaluated this on a 3 stage LLVM build on Windows 10 2004 (in vs2019 16.7.3 environment) on a 6-core i7-8700k.

• stage1 builds the scudo sanitizer on Windows: requires -DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt
• stage2: built with -DCMAKE_C_COMPILER="<stage1>/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="<stage1>/bin/clang-cl.exe" -DCMAKE_LINKER="<stage1>/bin/lld-link.exe" -DLLVM_USE_CRT_RELEASE=MT -DCMAKE_BUILD_TYPE=Release
• stage2_scudo: as stage2 plus -DLLVM_INTEGRATED_CRT_ALLOC=<stage1>/lib/clang/12.0.0/lib/windows/clang_rt.scudo-x86_64.lib

Then evaluated linking clang with ThinLTO:

• stage3: -DCMAKE_C_COMPILER="<stage2>/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="<stage2>/bin/clang-cl.exe" -DCMAKE_LINKER="<stage2>/bin/lld-link.exe" -DLLVM_USE_CRT_RELEASE=MT -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_LTO=Thin
• stage3_scudo: -DCMAKE_C_COMPILER="<stage2_scudo>/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="<stage2_scudo>/bin/clang-cl.exe" -DCMAKE_LINKER="<stage2_scudo>/bin/lld-link.exe" -DLLVM_USE_CRT_RELEASE=MT -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_LTO=Thin

I set /threads:12 and removed /lldltocache.

Without SCUDO_OPTIONS scudo seems to be about 25% slower.

>"hyperfine.exe" -m 3 -w 1 "cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt" "cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt"
Benchmark #1: cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt
  Time (mean ± σ):     268.209 s ±  4.966 s    [User: 18.1 ms, System: 6.6 ms]
  Range (min … max):   263.223 s … 273.155 s    3 runs

Benchmark #2: cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt
  Time (mean ± σ):     334.312 s ±  4.002 s    [User: 2.4 ms, System: 14.6 ms]
  Range (min … max):   329.889 s … 337.683 s    3 runs

Summary
  'cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt' ran
    1.25 ± 0.03 times faster than 'cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt'

I set scudo options to disable quarantine and mismatch checking and it seems to be about 8% slower.

>set SCUDO_OPTIONS=allocator_release_to_os_interval_ms=-1:QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0:DeleteSizeMismatch=0:DeallocationTypeMismatch=0
>"hyperfine.exe" -m 3 -w 1 "cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt" "cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt"
Benchmark #1: cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt
  Time (mean ± σ):     273.772 s ±  3.624 s    [User: 1.3 ms, System: 8.6 ms]
  Range (min … max):   269.806 s … 276.909 s    3 runs

Benchmark #2: cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt
  Time (mean ± σ):     296.593 s ±  2.362 s    [User: 1.3 ms, System: 13.9 ms]
  Range (min … max):   293.917 s … 298.391 s    3 runs

Summary
  'cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt' ran
    1.08 ± 0.02 times faster than 'cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt'

It's worth noting that the run without scudo was not using all CPU so still hitting some locking issues but was still over 90%. With both scudo runs it was pegged at 100% CPU until near the end of the link. From this it appears that the locking behaviour is better than the default allocator and would win out on a wide enough processor. The loss in straight line performance is potentially due to CRC calculations not using hardware support.

[russell.gallop]

In D86694#2242150, @russell.gallop wrote:

Is there a good sanity check that it is actually using Scudo rather than silently using the standard alloc?

It turns out is wasn't actually using scudo, it is now!

In D86694#2242559, @cryptoad wrote:

Nothing except the tests. Compiling a sizeable application with Scudo as well.

Compiling clang and lld with Scudo and ThinLTO linking clang seems to work.

The other point that is worth mentioning is that we moved all dev efforts to the "standalone" version of Scudo (eg: the one not depending on sanitizer_common in the standalone/ subdirectory).
There is enough differences that there could be some significant performance/mem footprint changes between the 2.

Thanks. I'm looking at porting the standalone variant, drawing on D42519 and Windows support from sanitizer_common. Does that sound like a reasonable approach?

Also depending on what you want to compare, disabling the Quarantine and other optional security features will make things faster and use less memory.

Would these be good flags to use:

set SCUDO_OPTIONS=allocator_release_to_os_interval_ms=-1:QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0:DeleteSizeMismatch=0:DeallocationTypeMismatch=0

[cryptoad]

In D86694#2268182, @russell.gallop wrote:

Thanks. I'm looking at porting the standalone variant, drawing on D42519 and Windows support from sanitizer_common. Does that sound like a reasonable approach?

Yup, the structure is a tad different, and other platforms (Fuchsia, Linux cpp) have some implementation of the platform specific functions.

Would these be good flags to use:

set SCUDO_OPTIONS=allocator_release_to_os_interval_ms=-1:QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0:DeleteSizeMismatch=0:DeallocationTypeMismatch=0

Yup, no release, no quarantine is a great. Size class map compile time options could also make a difference.

[aganea]

@russell.gallop Do you think you can upload the patch again by setting the Repository to "Monorepo"?

NVM I managed to do it. It's such a nightmare to apply patches when the above is not set upon uploading :-(

[aganea]

Thanks for working on this @russell.gallop!

I've reproduced your tests, please see below. The only difference is that I've used a ThinLTO build for stage2:
-DCMAKE_CXX_FLAGS="/GS- -Xclang -O3 -fstrict-aliasing -march=skylake-avx512 -flto=thin -fwhole-program-vtables.
Running with /opt:lldltojobs=all no /lldltocache.
Results on a 36-core (dual mount) Xeon Gold 6140, Windows 10 version 2004.

(WinHeap vs. Scudo+options)

D:\llvm-project>hyperfine -m 3 -w 1 "cd d:\llvm-project\buildninjaRelWinHeap3 && d:\llvm-project\buildninjaRelWinHeap2\bin\lld-link.exe @CMakeFiles\clang.rsp" "cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp"
Benchmark #1: cd d:\llvm-project\buildninjaRelWinHeap3 && d:\llvm-project\buildninjaRelWinHeap2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     664.086 s ± 18.740 s    [User: 0.0 ms, System: 0.0 ms]                                         
  Range (min … max):   647.070 s … 684.172 s    3 runs

Benchmark #2: cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     145.619 s ±  0.140 s    [User: 0.0 ms, System: 8.1 ms]                                         
  Range (min … max):   145.522 s … 145.779 s    3 runs

Summary
  'cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp' ran
    4.56 ± 0.13 times faster than 'cd d:\llvm-project\buildninjaRelWinHeap3 && d:\llvm-project\buildninjaRelWinHeap2\bin\lld-link.exe @CMakeFiles\clang.rsp'

(Scudo+options vs. Rpmalloc)

D:\llvm-project>hyperfine -m 3 -w 1 "cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp" "cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp"
Benchmark #1: cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     95.423 s ±  0.830 s    [User: 0.0 ms, System: 9.0 ms]                                          
  Range (min … max):   94.886 s … 96.380 s    3 runs

Benchmark #2: cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     145.266 s ±  0.387 s    [User: 4.9 ms, System: 7.6 ms]                                         
  Range (min … max):   144.894 s … 145.666 s    3 runs

Summary
  'cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp' ran
    1.52 ± 0.01 times faster than 'cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp'

(Scudo vs. Rpmalloc)

D:\llvm-project>hyperfine -m 3 -w 1 "cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp" "cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp"
Benchmark #1: cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     95.435 s ±  0.059 s    [User: 0.0 ms, System: 8.0 ms]                                          
  Range (min … max):   95.385 s … 95.499 s    3 runs

Benchmark #2: cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp
  Time (mean ± σ):     270.967 s ±  1.366 s    [User: 4.8 ms, System: 0.0 ms]                                        
  Range (min … max):   269.397 s … 271.887 s    3 runs

Summary
  'cd d:\llvm-project\buildninjaRelRpmalloc3 && d:\llvm-project\buildninjaRelRpMalloc2\bin\lld-link.exe @CMakeFiles\clang.rsp' ran
    2.84 ± 0.01 times faster than 'cd d:\llvm-project\buildninjaRelScudo3 && d:\llvm-project\buildninjaRelScudo2\bin\lld-link.exe @CMakeFiles\clang.rsp'

Summary:

	Time	Factor
WinHeap	664.086 s ± 18.740 s	1.0
Scudo	270.967 s ± 1.366 s	2.45
Scudo+options	145.619 s ± 0.140 s	4.56
Rpmalloc	95.423 s ± 0.830 s	6.95

CPU usage:
Rpmaloc - 3,944 cumulated seconds (all threads)

Scudo+options - 6,337 cumulated seconds (all threads)

Time spent in the allocator itself (note the different vertical scale in the graph)
(a hardware CRC or AES implemention will certainly help for Scudo)
Rpmalloc - 191 cumulated seconds

Scudo+options - 1,171 cumulated seconds

Memory usage:
Rpmalloc - Peaks at 11 GB commit (19 GB mapped)

Scudo+options - Peaks at 5 GB commit (although 4.4 TB of mapped pages!!!)

[russell.gallop]

Re-upload patch with G LLVM Github Monorepo set.

[russell.gallop]

In D86694#2270433, @aganea wrote:

Thanks for working on this @russell.gallop!

I've reproduced your tests, please see below. The only difference is that I've used a ThinLTO build for stage2:

Thanks. It's good to know they're reproducible, and that it scales better than the default allocator.

(a hardware CRC or AES implemention will certainly help for Scudo)

Actually this wasn't too hard to try out. I added "-msse4.2" to CMAKE_C_FLAGS and CMAKE_CXX_FLAGS (as suggested in scudo_allocator.cpp). This helps, but scudo is still a bit behind the default allocator for me on 6 cores:

> set SCUDO_OPTIONS=allocator_release_to_os_interval_ms=-1:QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0:DeleteSizeMismatch=0:DeallocationTypeMismatch=0
> hyperfine.exe -m 5 -w 1 "cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt" "cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt"
Benchmark #1: cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt
  Time (mean ± σ):     269.922 s ±  2.706 s    [User: 0.0 ms, System: 18.6 ms]
  Range (min … max):   265.969 s … 272.188 s    5 runs

Benchmark #2: cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt
  Time (mean ± σ):     285.522 s ±  0.440 s    [User: 12.3 ms, System: 9.9 ms]
  Range (min … max):   284.907 s … 286.056 s    5 runs

Summary
  'cd stage3\repro && f:\git\llvm-project\stage2\bin\lld-link @response.txt' ran
    1.06 ± 0.01 times faster than 'cd stage3_scudo\repro && f:\git\llvm-project\stage2_scudo\bin\lld-link @response.txt'

[aganea]

@russell.gallop I see a lots of failing tests when running ninja check-all on a Scudo-enabled build (stage 2). Do you see the same thing on your end?

==89136==ERROR: Scudo failed to allocate 0x10000 (65536) bytes of memory at address 0x4c0090e00 (error code: 1455)
==89136==Dumping process modules:
ERROR: Failed to mmap

If 4.4 TB of virtual pages are mapped in each process (this happens on startup), then we quickly exaust the 48-bit (256 TB) addressable space with 72+ programs running (on a 36-core). Any idea where this 4.4 TB mapping comes from?

Also, the infamous DynamicLibrary.Shutdown unittest fails with Scudo, like with SnMalloc. That test covers a tricky situation at shutdown.

[cryptoad]

In D86694#2273815, @aganea wrote:

If 4.4 TB of virtual pages are mapped in each process (this happens on startup), then we quickly exaust the 48-bit (256 TB) addressable space with 72+ programs running (on a 36-core). Any idea where this 4.4 TB mapping comes from?

The size of the Primary is defined in https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/scudo/scudo_platform.h#L75
Scudo reserves that size but doesn't commit it, then it incrementally commits when memory is needed within the reserved region.

[russell.gallop]

In D86694#2273815, @aganea wrote:

@russell.gallop I see a lots of failing tests when running ninja check-all on a Scudo-enabled build (stage 2). Do you see the same thing on your end?

Not a lot but a few, including DynamicLibrary.Shutdown:

Failed Tests (4):
  LLVM-Unit :: Support/DynamicLibrary/./DynamicLibraryTests.exe/DynamicLibrary.Shutdown
  LLVM :: ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll
  LLVM :: ExecutionEngine/OrcMCJIT/multi-module-sm-pic-a.ll
  LLVM :: ExecutionEngine/OrcMCJIT/stubs-sm-pic.ll

And the MCJIT ones seem intermittent (different ones fail each time).

If 4.4 TB of virtual pages are mapped in each process (this happens on startup), then we quickly exhaust the 48-bit (256 TB) addressable space with 72+ programs running (on a 36-core). Any idea where this 4.4 TB mapping comes from?

I guess that's just a problem with a larger number of cores then.

I'm going to concentrate on the standalone port as I think that's the way forward. If I get that working then can work through the other issues.

[russell.gallop]

In D86694#2274383, @cryptoad wrote:

In D86694#2273815, @aganea wrote:

If 4.4 TB of virtual pages are mapped in each process (this happens on startup), then we quickly exaust the 48-bit (256 TB) addressable space with 72+ programs running (on a 36-core). Any idea where this 4.4 TB mapping comes from?

The size of the Primary is defined in https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/scudo/scudo_platform.h#L75
Scudo reserves that size but doesn't commit it, then it incrementally commits when memory is needed within the reserved region.

I guess using scudo as a general purpose allocator that could set a limit on the number of cores that can be used at once as @aganea found. Would there be any problem with making this very small (e.g. a couple of GB)?

Thanks

[cryptoad]

In D86694#2274548, @russell.gallop wrote:

I guess using scudo as a general purpose allocator that could set a limit on the number of cores that can be used at once as @aganea found. Would there be any problem with making this very small (e.g. a couple of GB)?

You can reduce the size of the Primary for Windows with an additional define in the platform file. You probably want to make sure there is at least a few gigs per region (eg: the total size could be 256G).

Once again the memory is reserved but not committed, and this is on a per-process basis. There shouldn't be more than one Primary, and as such we shouldn't run out of VA space. We could possibly run out of memory if we allocate past the amount of RAM (+swap), but this is the committed amount.

[aganea]

In D86694#2274682, @cryptoad wrote:

In D86694#2274548, @russell.gallop wrote:

I guess using scudo as a general purpose allocator that could set a limit on the number of cores that can be used at once as @aganea found. Would there be any problem with making this very small (e.g. a couple of GB)?

You can reduce the size of the Primary for Windows with an additional define in the platform file. You probably want to make sure there is at least a few gigs per region (eg: the total size could be 256G).

Once again the memory is reserved but not committed, and this is on a per-process basis. There shouldn't be more than one Primary, and as such we shouldn't run out of VA space. We could possibly run out of memory if we allocate past the amount of RAM (+swap), but this is the committed amount.

I think reserving 4 TB hits a pathological case in the Windows NT Kernel, where for some reason, the application's VAD (Virtual Address Descriptor) tree is not cleared right away, but deferred to the system zero thread. Since that thread is low-priority, the VAD trees are accumulating in the "Active List", until it hits the physical memory limit, then it goes to swap, then at some point the VirtualAlloc calls in the application fail. This looks like an edge case that wouldn't happen normally (lots of applications that quickly start, reserve several TB of vRAM, then shutdown)
+ @maniccoder

As soon as I pause the ninja check-llvm tests (by blocking the console output), the zero thread now has more time and the free memory goes down again.

@cryptoad What happens if the primary was much smaller? Or if pages were reserved in much smaller ranges?

In D86694#2271825, @russell.gallop wrote:

(a hardware CRC or AES implemention will certainly help for Scudo)

Actually this wasn't too hard to try out. I added "-msse4.2" to CMAKE_C_FLAGS and CMAKE_CXX_FLAGS (as suggested in scudo_allocator.cpp). This helps, but scudo is still a bit behind the default allocator for me on 6 cores

This improves things a bit, wall clock 145 sec before -> 136 sec after.

Scudo+options+hardware-crc32 - 5,997 cumulated seconds (all threads) - before it was 6,337 seconds

Time spent in the allocator itself:

Scudo+options+hardware-crc32 - 761 cumulated seconds - before it was 1,171 seconds

There's one more thing. I think the difference in performance, as when compared with competing allocators, is that SCUDO still does some level of locking. Like I mentionned previously, this doesn't scale on many-core machine for allocation-intensive applications like LLVM. Every waiting lock gives up its time slice to the OS scheduler, and that's bad for performance. Also, the more core there are, the more we wait for the lock to become free.

Here you can see a Scudo-enabled LLD doing 10x more context-switches that the Rpmalloc-enabled LLD:

One thing that is in favor of Scudo though, is that it commits memory in much smaller blocks than Rpmalloc (peak LLD commit is 5 GB for Scudo, 11 GB for Rpmalloc). Mimalloc employs the same kind of strategy, with similar benefits.

@cryptoad Does SCUDO standalone differs in any of these aspects from this version?

[cryptoad]

In D86694#2277371, @aganea wrote:

@cryptoad What happens if the primary was much smaller? Or if pages were reserved in much smaller ranges?

The Primary can be made smaller, but this works better with the Standalone version as some code was added to fallback to larger class sizes if a region is full (Android uses 256mb per region).

@cryptoad Does SCUDO standalone differs in any of these aspects from this version?

So this requires a bit of background.
There are two models for the Thread Specific Data that holds the cached pointers: Shared (a pool of N caches is shared between all threads) and Exclusive (1 exclusive cache per thread).
For my initial port to Windows, I used the Shared model, with a pool of 32 caches max (it's a define in the platform header). If there is more than 32 cores, this can be increased.
I didn't try to make the Exclusive version work, mostly because I was using the Windows TLS API and the Shared fit right in with those, but it would get rid of a lot of the contention.

Overall with regard to the Standalone, it should be better on all accounts: faster (as we got rid of some of the quirks of sanitizer_common), lesser memory footprint, better reclaiming, more configurable.

[aganea]

In D86694#2277456, @cryptoad wrote:

I didn't try to make the Exclusive version work, mostly because I was using the Windows TLS API and the Shared fit right in with those, but it would get rid of a lot of the contention.

That sounds good. Right now, the delta between rpmalloc/mimalloc/snmalloc is less than 5 sec (for a run of 2 min 15 sec), I would assume with the Exclusive mode, SCUDO would fall in the same ballpark. Any other allocator that I've tried that does some level of locking (Hoard, ptmalloc, tcmalloc2) does not scale (is much slower) on many-cores machines.

[russell.gallop]

I'm going to concentrate on the standalone port as I think that's the way forward. If I get that working then can work through the other issues.

I'm considering a slight change of plan. @cryptoad, in the name of incremental development, would you be happy for me to put the scudo sanitizer version up (with working tests), or is this deprecated now? It may not be the best for performance long term but it's a smaller step than the standalone port and seems to work.

[cryptoad]

In D86694#2287242, @russell.gallop wrote:

I'm considering a slight change of plan. @cryptoad, in the name of incremental development, would you be happy for me to put the scudo sanitizer version up (with working tests), or is this deprecated now? It may not be the best for performance long term but it's a smaller step than the standalone port and seems to work.

Sounds good to me.

[aganea]

I'm also in favor, I think this is good direction ahead. It'd be nice if following issues were fixed -- in subsequent patches if you wish:

• Stage1 ninja check-scudo fails many tests for me, see
  errors.txt51 KBDownload
  .
• Stage2 ninja check-llvm fails after a while on high-core machines (4TB issue mentionned in comments above). Lowering AllocatorSize to 256GB would fix the issue on the short term.
• Fix & test the "exclusive" mode (or just skip to scudo-standalone if it's too complicated).

compiler-rt/lib/scudo/scudo_platform.h

67

&& SANITIZER_WINDOWS ?

compiler-rt/test/scudo/lit.cfg.py

19–20

Remove this line (duplicate).

llvm/lib/Support/CMakeLists.txt

61

Please also mention scudo in corresponding LLVM_INTEGRATED_CRT_ALLOC section in llvm/docs/CMake.rst.

[russell.gallop]

In D86694#2288660, @aganea wrote:

I'm also in favor, I think this is good direction ahead. It'd be nice if following issues were fixed -- in subsequent patches if you wish:

• Stage1 ninja check-scudo fails many tests for me, see
  errors.txt51 KBDownload
  .

I intend to fix these (or mark an unsupported) for this patch.

• Stage2 ninja check-llvm fails after a while on high-core machines (4TB issue mentionned in comments above). Lowering AllocatorSize to 256GB would fix the issue on the short term.

I'll add that.

• Fix & test the "exclusive" mode (or just skip to scudo-standalone if it's too complicated).

I don't intend to do that for this patch, as shared mode works. I will re-evaluate after the above.

I also intend to remove the -fsanitize related changes. I believe that they're not required on Windows.

Thanks
Russ

compiler-rt/lib/scudo/scudo_platform.h

67

I think that should be:

# if (defined(__aarch64__) && SANITIZER_ANDROID) || SANITIZER_WINDOWS

I'll either do that or add a new elif.

[russell.gallop]

Apologies for the delay, I've had a few other things on.

I've worked through the tests. Several I've marked as unsupported on windows as they use things unixy things like nm, LD_PRELOAD or fork(). I added a C++ threads version of threads.c to test that on Windows (cxx_threads.cpp).

There are 5 remaining failures:

Failed Tests (5):
  Scudo-x86_64 :: aligned-new.cpp
  Scudo-x86_64 :: mismatch.cpp
  Scudo-x86_64 :: options.cpp
  Scudo-x86_64 :: sized-delete.cpp
  Scudo-x86_64 :: sizes.cpp

Testing Time: 11.61s
  Unsupported:  8
  Passed     : 13
  Failed     :  5

These are all down to new/delete not being replaced by the scudo versions, so scudoAllocate and scudoDeallocate don't get the appropriate size and Type parameters. The cxx library should be linked by SanitizerArgs::addArgs so I'm not sure why this is. @cryptoad, it looks like you did some work in scudo_new_delete.cpp, did you have this working?

Does new/delete need to work for this, or should I mark these tests as unsupported on Windows for the purposes of a step towards getting the standalone scudo working?

Stage 2 builds with -DLLVM_INTEGRATED_CRT_ALLOC=<llvm-project>/stage1/lib/clang/12.0.0/lib/windows/clang_rt.scudo-x86_64.lib -DLLVM_USE_CRT_RELEASE=MT.

[cryptoad]

Thank you for all your work!
IIRC everything was working except as you point out some of the very Unixy tests.
Is your build creating a clang_rt.scudo_cxx library that also needs to be link as well? The C++ specific interceptors usually end up in a separate library that is not linked into the straight C programs, which is the most likely culprit for not having new/delete be intercepted.

In D86694#2360026, @russell.gallop wrote:

These are all down to new/delete not being replaced by the scudo versions, so scudoAllocate and scudoDeallocate don't get the appropriate size and Type parameters. The cxx library should be linked by SanitizerArgs::addArgs so I'm not sure why this is. @cryptoad, it looks like you did some work in scudo_new_delete.cpp, did you have this working?

Does new/delete need to work for this, or should I mark these tests as unsupported on Windows for the purposes of a step towards getting the standalone scudo working?

Stage 2 builds with -DLLVM_INTEGRATED_CRT_ALLOC=<llvm-project>/stage1/lib/clang/12.0.0/lib/windows/clang_rt.scudo-x86_64.lib -DLLVM_USE_CRT_RELEASE=MT.

[russell.gallop]

Apologies for the delay, I've had other things taking my time.

Latest version uploaded. This fixes stage1 lit tests (on Windows and Linux) and adds scudo_cxx to linking.

Usage has changed slightly, now -DLLVM_INTEGRATED_CRT_ALLOC should point to the directory with scudo built libraries (e.g. c:/git/llvm-project/stage1/lib/clang/12.0.0/lib/windows) rather than the library itself. -fsanitize=scudo works for the lit tests (as clang adds the libraries when driving the linker) but doesn't work for building LLVM as cmake links with the linker directly so this uses LLVM_INTEGRATED_CRT_ALLOC.

There are two issues I'm aware of now:

• Linking c-index-test.exe with scudo fails due to new being redefined

lld-link: error: void * __cdecl operator new(unsigned __int64) was replaced

Or from link.exe

clang_rt.scudo_cxx-x86_64.lib(scudo_new_delete.cpp.obj) : error LNK2005: "void * __cdecl operator new(unsigned __int64)" (??2@YAPEAX_K@Z) already defined in libclang.lib(libclang.dll)
...

• With scudo all lit tests (generally) pass, but there are some intermittent failures (Access Violation) on the following tests:

ExecutionEngine/MCJIT/test-global-init-nonzero-sm-pic.ll
ExecutionEngine/MCJIT/test-ptr-reloc-sm-pic.ll
ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll

This happens with VS2019 or clang-cl as the toolchain. I've run multiple times without scudo and don't see these. Unfortunately I haven't been able to get this to fail in a debugger.

[aganea]

In D86694#2463429, @russell.gallop wrote:

• With scudo all lit tests (generally) pass, but there are some intermittent failures (Access Violation) on the following tests:

ExecutionEngine/MCJIT/test-global-init-nonzero-sm-pic.ll
ExecutionEngine/MCJIT/test-ptr-reloc-sm-pic.ll
ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll

This happens with VS2019 or clang-cl as the toolchain. I've run multiple times without scudo and don't see these. Unfortunately I haven't been able to get this to fail in a debugger.

Could you possibly comment out sys::PrintStackTraceOnErrorSignal in InitLLVM.cpp, run specifically those tests several times through LIT until they crash, and attach when the popup shows up?

[russell.gallop]

Remove -fsanitize=scudo support for Windows in LLVM cmake, using LLVM_INTEGRATED_CRT_ALLOC instead.
Remove scudo_cxx from LLVM_INTEGRATED_CRT_ALLOC.

[russell.gallop]

I managed to get this to fail in the debugger (for the cross-module-sm-pic-a.ll test):

 	000001655e9d001e()	Unknown
 	000001655e9d0019()	Unknown
 	0000017e5eb6b410()	Unknown
 	0000017c5eb63810()	Unknown
 	0000017e5eb6b410()	Unknown
 	0000017e5eb6b410()	Unknown
 	0000016f5eb65b58()	Unknown
>	lli.exe!llvm::MCJIT::runFunction(llvm::Function * F, llvm::ArrayRef<llvm::GenericValue> ArgValues) Line 578	C++
 	lli.exe!llvm::ExecutionEngine::runFunctionAsMain(llvm::Function * Fn, const std::vector<std::string,std::allocator<std::string>> & argv, const char * const * envp) Line 467	C++
 	lli.exe!main(int argc, char * * argv, char * const * envp) Line 646	C++
 	[Inline Frame] lli.exe!invoke_main() Line 78	C++
 	lli.exe!__scrt_common_main_seh() Line 288	C++
 	kernel32.dll!00007ffd145a7034()	Unknown
 	ntdll.dll!00007ffd1657d0d1()	Unknown

It appears to be failing within the interpreted code. Maybe this is a problem between the memory allocator and the Memory Manager.

I tried running these tests repeatedly with scudo (sanitizer) on Linux but didn't see it fail. I also tried repeating these tests with rpmalloc on Windows and didn't see the failures so it does appear to be specific to scudo on Windows. I'll keep investigating.

[russell.gallop]

I've focussed on the test test-global-init-nonzero-sm-pic.ll which fails writing to an address which (I believe) should be in the .data section but isn't.

With some breakpoints in SectionMemoryManager.cpp it appears that this fails when the top 32bits of the .text allocated address and the .data allocated address are different:

Allocating Data section ".data"
Returning aligned address 0x000001ed 30f60000 of size 0x0000000000000004
Allocating code section ".text"
Returning aligned address 0x0000022d 31050000 of size 0x000000000000003a

And work when they happen to be the same. When this fails, the address causing the access violation is the top 32bits of the .text address and the bottom 32bits of the .data address, e.g. 0x0000022d 30f60000. This doesn't fail without scudo as the top 32bits of the addresses seem to always be the same.

With assertions enabled this is causing an assert:

f:\git\llvm-project\stage1_scudo>"f:\git\llvm-project\stage1_scudo\bin\lli.exe" "-mtriple=x86_64-pc-windows-msvc-elf" "-relocation-model=pic" "-code-model=small" "f:\git\llvm-project\llvm\test\ExecutionEngine\MCJIT\test-global-init-nonzero-sm-pic.ll"
Assertion failed: isInt<32>(RealOffset), file F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyldELF.cpp, line 300
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: f:\\git\\llvm-project\\stage1_scudo\\bin\\lli.exe -mtriple=x86_64-pc-windows-msvc-elf -relocation-model=pic -code-model=small f:\\git\\llvm-project\\llvm\\test\\ExecutionEngine\\MCJIT\\test-global-init-nonzero-sm-pic.ll
 #0 0x00007ff63eb423c5 HandleAbort F:\git\llvm-project\llvm\lib\Support\Windows\Signals.inc:408:0
 #1 0x00007ff63f89d951 raise minkernel\crts\ucrt\src\appcrt\misc\signal.cpp:547:0
 #2 0x00007ff63f8617cc abort minkernel\crts\ucrt\src\appcrt\startup\abort.cpp:71:0
 #3 0x00007ff63f8825b8 common_assert_to_stderr<wchar_t> minkernel\crts\ucrt\src\appcrt\startup\assert.cpp:175:0
 #4 0x00007ff63f882d42 _wassert minkernel\crts\ucrt\src\appcrt\startup\assert.cpp:443:0
 #5 0x00007ff63e749e96 llvm::RuntimeDyldELF::resolveX86_64Relocation(class llvm::SectionEntry const &, unsigned __int64, unsigned __int64, unsigned int, __int64, unsigned __int64) F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyldELF.cpp:302:0
 #6 0x00007ff63e7496be llvm::RuntimeDyldELF::resolveRelocation(class llvm::RelocationEntry const &, unsigned __int64) F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyldELF.cpp:932:0
 #7 0x00007ff63e72e656 llvm::RuntimeDyldImpl::resolveRelocationList(class llvm::SmallVector<class llvm::RelocationEntry, 64> const &, unsigned __int64) F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyld.cpp:1077:0
 #8 0x00007ff63e72e52c ::operator++ C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\include\list:166:0
 #9 0x00007ff63e72e52c ::operator++ C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\include\list:247:0
#10 0x00007ff63e72e52c llvm::RuntimeDyldImpl::resolveLocalRelocations(void) F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyld.cpp:145:0
#11 0x00007ff63e72e872 llvm::RuntimeDyldImpl::resolveRelocations(void) F:\git\llvm-project\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyld.cpp:139:0
#12 0x00007ff63e532601 llvm::MCJIT::finalizeLoadedModules(void) F:\git\llvm-project\llvm\lib\ExecutionEngine\MCJIT\MCJIT.cpp:245:0
#13 0x00007ff63e532bfd ::{dtor} F:\git\llvm-project\llvm\include\llvm\ADT\SmallVector.h:1045:0
#14 0x00007ff63e532bfd llvm::MCJIT::finalizeObject(void) F:\git\llvm-project\llvm\lib\ExecutionEngine\MCJIT\MCJIT.cpp:271:0
#15 0x00007ff63dcfa06c main F:\git\llvm-project\llvm\tools\lli\lli.cpp:633:0
#16 0x00007ff63f81527c invoke_main d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78:0
#17 0x00007ff63f81527c __scrt_common_main_seh d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0
#18 0x00007ffd145a7034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034)
#19 0x00007ffd1657d0d1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x4d0d1)

[russell.gallop]

I believe that the MCJIT failures are due to bug https:/bugs.llvm.org/show_bug.cgi?id=24978 rather than a problem in the Scudo port so I have added details of how I hit it to that bugzilla and opened two reviews to get this landed:
https://reviews.llvm.org/D96120 - [scudo] Port scudo sanitizer to Windows
https://reviews.llvm.org/D96133 - Allow building with scudo memory allocator on Windows

Please can you take a look?

I have not added the LLVM_USE_SANITIZER support for scudo from this review. -fsanitize adds scudo libraries when the linker is driven from clang, and the LLVM cmake build on Windows uses link.exe directly so this doesn't help. And scudo sanitizer is planned to go away so I didn't think it made sense to add that support on Linux either.

clang/lib/Driver/ToolChains/MSVC.cpp

if (TC.getSanitizerArgs().needsSharedRt() ||
         // This is necessary because instrumented dlls need access to all the
         // interface exported by the static lib in the main executable.
         CmdArgs.push_back(Args.MakeArgString(std::string("-wholearchive:") +
             TC.getCompilerRT(Args, Lib)));
       }
     }
   }
 
+  if (TC.getSanitizerArgs().needsScudoRt()) {
+    for (const auto &Lib : {"scudo", "scudo_cxx"}) {
+      CmdArgs.push_back(TC.getCompilerRTArgString(Args, Lib));
+    }
+    CmdArgs.push_back(Args.MakeArgString("-include:malloc"));
+  }
+
   Args.AddAllArgValues(CmdArgs, options::OPT__SLASH_link);
 
   // Control Flow Guard checks
   if (Arg *A = Args.getLastArg(options::OPT__SLASH_guard)) {
     StringRef GuardArgs = A->getValue();
     if (GuardArgs.equals_lower("cf") || GuardArgs.equals_lower("cf,nochecks")) {
       // MSVC doesn't yet support the "nochecks" modifier.
       CmdArgs.push_back("-guard:cf");

 
 SanitizerMask MSVCToolChain::getSupportedSanitizers() const {
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
   Res |= SanitizerKind::PointerCompare;
   Res |= SanitizerKind::PointerSubtract;
   Res |= SanitizerKind::Fuzzer;
   Res |= SanitizerKind::FuzzerNoLink;
+  Res |= SanitizerKind::Scudo;
   Res &= ~SanitizerKind::CFIMFCall;
   return Res;
 }
 
 static void TranslateOptArg(Arg *A, llvm::opt::DerivedArgList &DAL,
                             bool SupportsForcingFramePointer,
                             const char *ExpandChar, const OptTable &Opts) {
   assert(A->getOption().matches(options::OPT__SLASH_O));

compiler-rt/cmake/config-ix.cmake

if (COMPILER_RT_HAS_NODEFAULTLIBS_FLAG)
   endif()
 endif ()
 
 # CodeGen options.
 check_c_compiler_flag(-ffreestanding         COMPILER_RT_HAS_FFREESTANDING_FLAG)
 check_c_compiler_flag(-std=c11               COMPILER_RT_HAS_STD_C11_FLAG)
 check_cxx_compiler_flag(-fPIC                COMPILER_RT_HAS_FPIC_FLAG)
 check_cxx_compiler_flag(-fPIE                COMPILER_RT_HAS_FPIE_FLAG)
+check_cxx_compiler_flag(-fbuiltin            COMPILER_RT_HAS_FBUILTIN_FLAG)
 check_cxx_compiler_flag(-fno-builtin         COMPILER_RT_HAS_FNO_BUILTIN_FLAG)
 check_cxx_compiler_flag(-fno-exceptions      COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG)
 check_cxx_compiler_flag(-fomit-frame-pointer COMPILER_RT_HAS_FOMIT_FRAME_POINTER_FLAG)
 check_cxx_compiler_flag(-funwind-tables      COMPILER_RT_HAS_FUNWIND_TABLES_FLAG)
 check_cxx_compiler_flag(-fno-stack-protector COMPILER_RT_HAS_FNO_STACK_PROTECTOR_FLAG)
 check_cxx_compiler_flag(-fno-sanitize=safe-stack COMPILER_RT_HAS_FNO_SANITIZE_SAFE_STACK_FLAG)
 check_cxx_compiler_flag(-fvisibility=hidden  COMPILER_RT_HAS_FVISIBILITY_HIDDEN_FLAG)
 check_cxx_compiler_flag(-frtti               COMPILER_RT_HAS_FRTTI_FLAG)

 endif()
 check_linker_flag("${VERS_OPTION}" COMPILER_RT_HAS_VERSION_SCRIPT)
 
 if(ANDROID)
   check_linker_flag("-Wl,-z,global" COMPILER_RT_HAS_Z_GLOBAL)
   check_library_exists(log __android_log_write "" COMPILER_RT_HAS_LIBLOG)
 endif()
 
+check_linker_flag("-Wl,--gc-sections" COMPILER_RT_HAS_GC_SECTIONS)
+
 # Architectures.
 
 # List of all architectures we can target.
 set(COMPILER_RT_SUPPORTED_ARCH)
 
 # Try to compile a very simple source file to ensure we can target the given
 # platform. We use the results of these tests to build only the various target
 # runtime libraries supported by our current compilers cross-compiling

 if (SCUDO_STANDALONE_SUPPORTED_ARCH AND OS_NAME MATCHES "Linux" AND
     COMPILER_RT_HAS_AUXV)
   set(COMPILER_RT_HAS_SCUDO_STANDALONE TRUE)
 else()
   set(COMPILER_RT_HAS_SCUDO_STANDALONE FALSE)
 endif()
 
 if (COMPILER_RT_HAS_SANITIZER_COMMON AND SCUDO_SUPPORTED_ARCH AND
-    OS_NAME MATCHES "Linux|Android|Fuchsia")
+    OS_NAME MATCHES "Linux|Android|Fuchsia|Windows")
   set(COMPILER_RT_HAS_SCUDO TRUE)
 else()
   set(COMPILER_RT_HAS_SCUDO FALSE)
 endif()
 
 if (COMPILER_RT_HAS_SANITIZER_COMMON AND XRAY_SUPPORTED_ARCH AND
     OS_NAME MATCHES "Darwin|Linux|FreeBSD|NetBSD|Fuchsia")
   set(COMPILER_RT_HAS_XRAY TRUE)

compiler-rt/lib/sanitizer_common/sanitizer_win.cpp

 
 #define WIN32_LEAN_AND_MEAN
 #define NOGDI
 #include <windows.h>
 #include <io.h>
 #include <psapi.h>
 #include <stdlib.h>
 
+// #define needed to link in RtlGenRandom(), a.k.a. SystemFunction036.  See the
+// "Community Additions" comment on MSDN here:
+// http://msdn.microsoft.com/en-us/library/windows/desktop/aa387694.aspx
+#define SystemFunction036 NTAPI SystemFunction036
+#include <NTSecAPI.h>
+#undef SystemFunction036
+
 #include "sanitizer_common.h"
 #include "sanitizer_file.h"
 #include "sanitizer_libc.h"
 #include "sanitizer_mutex.h"
 #include "sanitizer_placement_new.h"
 #include "sanitizer_win_defs.h"
 
 #if defined(PSAPI_VERSION) && PSAPI_VERSION == 1

 
 // FIXME implement on this platform.
 void GetMemoryProfile(fill_profile_f cb, uptr *stats, uptr stats_size) { }
 
 void CheckNoDeepBind(const char *filename, int flag) {
   // Do nothing.
 }
 
-// FIXME: implement on this platform.
+#pragma comment(lib, "advapi32.lib")
 bool GetRandom(void *buffer, uptr length, bool blocking) {
-  UNIMPLEMENTED();
+  if (!buffer || !length || length > 256)
+    return false;
+  return RtlGenRandom(buffer, length) != FALSE;
 }
 
 u32 GetNumberOfCPUs() {
   SYSTEM_INFO sysinfo = {};
   GetNativeSystemInfo(&sysinfo);
   return sysinfo.dwNumberOfProcessors;
 }
 

compiler-rt/lib/scudo/CMakeLists.txt

 add_compiler_rt_component(scudo)
 
 include_directories(..)
 
 set(SCUDO_CFLAGS ${SANITIZER_COMMON_CFLAGS})
 # SANITIZER_COMMON_CFLAGS include -fno-builtin, but we actually want builtins!
+if (COMPILER_RT_HAS_FBUILTIN_FLAG)
   list(APPEND SCUDO_CFLAGS -fbuiltin)
+endif()
 append_rtti_flag(OFF SCUDO_CFLAGS)
 
 set(SCUDO_MINIMAL_DYNAMIC_LIBS ${SANITIZER_COMMON_LINK_LIBS})
 append_list_if(COMPILER_RT_HAS_LIBDL dl SCUDO_MINIMAL_DYNAMIC_LIBS)
 append_list_if(COMPILER_RT_HAS_LIBRT rt SCUDO_MINIMAL_DYNAMIC_LIBS)
 append_list_if(COMPILER_RT_HAS_LIBPTHREAD pthread SCUDO_MINIMAL_DYNAMIC_LIBS)
 append_list_if(COMPILER_RT_HAS_LIBLOG log SCUDO_MINIMAL_DYNAMIC_LIBS)
 append_list_if(COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG -fno-omit-frame-pointer
                SCUDO_CFLAGS)
 
 set(SCUDO_DYNAMIC_LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS})
 # Use gc-sections by default to avoid unused code being pulled in.
+if (COMPILER_RT_HAS_GC_SECTIONS)
   list(APPEND SCUDO_DYNAMIC_LINK_FLAGS -Wl,--gc-sections)
+endif()
 
 if(ANDROID)
 # Put most Sanitizer shared libraries in the global group. For more details, see
 # android-changes-for-ndk-developers.md#changes-to-library-search-order
   if (COMPILER_RT_HAS_Z_GLOBAL)
     list(APPEND SCUDO_DYNAMIC_LINK_FLAGS -Wl,-z,global)
   endif()
 endif()

compiler-rt/lib/scudo/scudo_allocator.cpp

 
 // Global static cookie, initialized at start-up.
 static u32 Cookie;
 
 // We default to software CRC32 if the alternatives are not supported, either
 // at compilation or at runtime.
 static atomic_uint8_t HashAlgorithm = { CRC32Software };
 
+#if !SANITIZER_SUPPORTS_WEAK_HOOKS
+SANITIZER_WEAK_ATTRIBUTE u32 computeHardwareCRC32(u32 Crc, uptr Data) {
+  return computeSoftwareCRC32(Crc, Data);
+}
+#endif
+
 inline u32 computeCRC32(u32 Crc, uptr Value, uptr *Array, uptr ArraySize) {
   // If the hardware CRC32 feature is defined here, it was enabled everywhere,
   // as opposed to only for scudo_crc32.cpp. This means that other hardware
   // specific instructions were likely emitted at other places, and as a
   // result there is no reason to not use it here.
 #if defined(__SSE4_2__) || defined(__ARM_FEATURE_CRC32)
   Crc = CRC32_INTRINSIC(Crc, Value);
   for (uptr i = 0; i < ArraySize; i++)
NOINLINE void Allocator::performSanityChecks() {
   // offset will always be 0. In the case of the Primary, the worst case
   // scenario happens in the last size class, when the backend allocation
   // would already be aligned on the requested alignment, which would happen
   // to be the maximum alignment that would fit in that size class. As a
   // result, the maximum offset will be at most the maximum alignment for the
   // last size class minus the header size, in multiples of MinAlignment.
   UnpackedHeader Header = {};
   const uptr MaxPrimaryAlignment =
-      1 << MostSignificantSetBitIndex(SizeClassMap::kMaxSize - MinAlignment);
+      (uptr)1U << MostSignificantSetBitIndex(SizeClassMap::kMaxSize - MinAlignment);
   const uptr MaxOffset =
       (MaxPrimaryAlignment - Chunk::getHeaderSize()) >> MinAlignmentLog;
   Header.Offset = MaxOffset;
   if (Header.Offset != MaxOffset)
     dieWithMessage("maximum possible offset doesn't fit in header\n");
   // Verify that we can fit the maximum size or amount of unused bytes in the
   // header. Given that the Secondary fits the allocation to a page, the worst
   // case scenario happens in the Primary. It will depend on the second to

compiler-rt/lib/scudo/scudo_crc32.cpp

 /// kept separated to restrict the use of compiler specific flags to this file.
 ///
 //===----------------------------------------------------------------------===//
 
 #include "scudo_crc32.h"
 
 namespace __scudo {
 
+// Can't override this with weak symbols on Windows
+#if !defined(_WIN32)
 #if defined(__SSE4_2__) || defined(__ARM_FEATURE_CRC32)
 u32 computeHardwareCRC32(u32 Crc, uptr Data) {
   return CRC32_INTRINSIC(Crc, Data);
 }
 #endif  // defined(__SSE4_2__) || defined(__ARM_FEATURE_CRC32)
+#endif  // defined(_WIN32)
 
 }  // namespace __scudo

compiler-rt/lib/scudo/scudo_new_delete.cpp

 #include "scudo_errors.h"
 
 #include "interception/interception.h"
 
 #include <stddef.h>
 
 using namespace __scudo;
 
+// C++ operators can't have dllexport attributes on Windows. We export them
+// anyway by passing extra -export flags to the linker, which is exactly that
+// dllexport would normally do. We need to export them in order to make the
+// VS2015 dynamic CRT (MD) work.
+#if SANITIZER_WINDOWS
+#define CXX_OPERATOR_ATTRIBUTE
+#define COMMENT_EXPORT(sym) __pragma(comment(linker, "/export:" sym))
+#ifdef _WIN64
+COMMENT_EXPORT("??2@YAPEAX_K@Z")                    // operator new
+COMMENT_EXPORT("??2@YAPEAX_KAEBUnothrow_t@std@@@Z") // operator new nothrow
+COMMENT_EXPORT("??3@YAXPEAX@Z")                     // operator delete
+COMMENT_EXPORT("??3@YAXPEAX_K@Z")                   // sized operator delete
+COMMENT_EXPORT("??_U@YAPEAX_K@Z")                   // operator new[]
+COMMENT_EXPORT("??_V@YAXPEAX@Z")                    // operator delete[]
+#else
+COMMENT_EXPORT("??2@YAPAXI@Z")                   // operator new
+COMMENT_EXPORT("??2@YAPAXIABUnothrow_t@std@@@Z") // operator new nothrow
+COMMENT_EXPORT("??3@YAXPAX@Z")                   // operator delete
+COMMENT_EXPORT("??3@YAXPAXI@Z")                  // sized operator delete
+COMMENT_EXPORT("??_U@YAPAXI@Z")                  // operator new[]
+COMMENT_EXPORT("??_V@YAXPAX@Z")                  // operator delete[]
+#endif
+#undef COMMENT_EXPORT
+#else
 #define CXX_OPERATOR_ATTRIBUTE INTERCEPTOR_ATTRIBUTE
+#endif
 
 // Fake std::nothrow_t to avoid including <new>.
 namespace std {
 struct nothrow_t {};
 enum class align_val_t: size_t {};
 }  // namespace std
 
 // TODO(alekseys): throw std::bad_alloc instead of dying on OOM.

compiler-rt/lib/scudo/scudo_platform.h

 ///
 //===----------------------------------------------------------------------===//
 
 #ifndef SCUDO_PLATFORM_H_
 #define SCUDO_PLATFORM_H_
 
 #include "sanitizer_common/sanitizer_allocator.h"
 
-#if !SANITIZER_LINUX && !SANITIZER_FUCHSIA
+#if !SANITIZER_LINUX && !SANITIZER_FUCHSIA && !SANITIZER_WINDOWS
 # error "The Scudo hardened allocator is not supported on this platform."
 #endif
 
-#define SCUDO_TSD_EXCLUSIVE_SUPPORTED (!SANITIZER_ANDROID && !SANITIZER_FUCHSIA)
+#define SCUDO_TSD_EXCLUSIVE_SUPPORTED                                          \
+  (!SANITIZER_ANDROID && !SANITIZER_FUCHSIA && !SANITIZER_WINDOWS)
 
 #ifndef SCUDO_TSD_EXCLUSIVE
 // SCUDO_TSD_EXCLUSIVE wasn't defined, use a default TSD model for the platform.
-# if SANITIZER_ANDROID || SANITIZER_FUCHSIA
-// Android and Fuchsia use a pool of TSDs shared between threads.
-#  define SCUDO_TSD_EXCLUSIVE 0
-# elif SANITIZER_LINUX && !SANITIZER_ANDROID
-// Non-Android Linux use an exclusive TSD per thread.
+#if SCUDO_TSD_EXCLUSIVE_SUPPORTED
 #  define SCUDO_TSD_EXCLUSIVE 1
 # else
-#  error "No default TSD model defined for this platform."
-# endif  // SANITIZER_ANDROID || SANITIZER_FUCHSIA
-#endif  // SCUDO_TSD_EXCLUSIVE
-
+#define SCUDO_TSD_EXCLUSIVE 0
+#endif // SCUDO_TSD_EXCLUSIVE_SUPPORTED
+#else
 // If the exclusive TSD model is chosen, make sure the platform supports it.
 #if SCUDO_TSD_EXCLUSIVE && !SCUDO_TSD_EXCLUSIVE_SUPPORTED
 # error "The exclusive TSD model is not supported on this platform."
 #endif
+#endif // SCUDO_TSD_EXCLUSIVE
 
 // Maximum number of TSDs that can be created for the Shared model.
 #ifndef SCUDO_SHARED_TSD_POOL_SIZE
 # if SANITIZER_ANDROID
 #  define SCUDO_SHARED_TSD_POOL_SIZE 2U
 # else
 #  define SCUDO_SHARED_TSD_POOL_SIZE 32U
 # endif  // SANITIZER_ANDROID

 # else
 #  define SCUDO_CAN_USE_HOOKS 0
 # endif  // SANITIZER_FUCHSIA
 #endif  // SCUDO_CAN_USE_HOOKS
 
 namespace __scudo {
 
 #if SANITIZER_CAN_USE_ALLOCATOR64
 # if defined(__aarch64__) && SANITIZER_ANDROID
 const uptr AllocatorSize = 0x4000000000ULL;  // 256G.
 # elif defined(__aarch64__)
 const uptr AllocatorSize = 0x10000000000ULL;  // 1T.
+#elif SANITIZER_WINDOWS
+const uptr AllocatorSize = 0x4000000000ULL; // 256G.
 # else
 const uptr AllocatorSize = 0x40000000000ULL;  // 4T.
 # endif
 #else
 const uptr RegionSizeLog = SANITIZER_ANDROID ? 19 : 20;
 #endif  // SANITIZER_CAN_USE_ALLOCATOR64
 
 #if !defined(SCUDO_SIZE_CLASS_MAP)

compiler-rt/lib/scudo/scudo_tsd.h

 //===----------------------------------------------------------------------===//
 
 #ifndef SCUDO_TSD_H_
 #define SCUDO_TSD_H_
 
 #include "scudo_allocator.h"
 #include "scudo_utils.h"
 
+#if !SANITIZER_WINDOWS
 #include <pthread.h>
+#else
+#include <windows.h>
+#endif // SANITIZER_WINDOWS
 
 namespace __scudo {
 
 struct ALIGNED(SANITIZER_CACHE_LINE_SIZE) ScudoTSD {
   AllocatorCacheT Cache;
   uptr QuarantineCachePlaceHolder[4];
 
   void init();

compiler-rt/lib/scudo/scudo_tsd_shared.cpp

 //===----------------------------------------------------------------------===//
 
 #include "scudo_tsd.h"
 
 #if !SCUDO_TSD_EXCLUSIVE
 
 namespace __scudo {
 
+#if !SANITIZER_WINDOWS
 static pthread_once_t GlobalInitialized = PTHREAD_ONCE_INIT;
 pthread_key_t PThreadKey;
+#else
+DWORD TlsIndex = TLS_OUT_OF_INDEXES;
+static INIT_ONCE InitOnce = INIT_ONCE_STATIC_INIT;
+#endif
 
 static atomic_uint32_t CurrentIndex;
 static ScudoTSD *TSDs;
 static u32 NumberOfTSDs;
 static u32 CoPrimes[SCUDO_SHARED_TSD_POOL_SIZE];
 static u32 NumberOfCoPrimes = 0;
 
 #if SANITIZER_LINUX && !SANITIZER_ANDROID
 __attribute__((tls_model("initial-exec")))
 THREADLOCAL ScudoTSD *CurrentTSD;
 #endif
 
 static void initOnce() {
+#if SANITIZER_WINDOWS
+  TlsIndex = TlsAlloc();
+  CHECK_NE(TlsIndex, TLS_OUT_OF_INDEXES);
+#elif !SANITIZER_ANDROID
   CHECK_EQ(pthread_key_create(&PThreadKey, NULL), 0);
+#endif
   initScudo();
   NumberOfTSDs = Min(Max(1U, GetNumberOfCPUsCached()),
                      static_cast<u32>(SCUDO_SHARED_TSD_POOL_SIZE));
   TSDs = reinterpret_cast<ScudoTSD *>(
       MmapOrDie(sizeof(ScudoTSD) * NumberOfTSDs, "ScudoTSDs"));
   for (u32 I = 0; I < NumberOfTSDs; I++) {
     TSDs[I].init();
     u32 A = I + 1;
     u32 B = NumberOfTSDs;
     while (B != 0) { const u32 T = A; A = B; B = T % B; }
     if (A == 1)
       CoPrimes[NumberOfCoPrimes++] = I + 1;
   }
 }
 
 ALWAYS_INLINE void setCurrentTSD(ScudoTSD *TSD) {
-#if SANITIZER_ANDROID
+#if SANITIZER_WINDOWS
+  CHECK(TlsSetValue(TlsIndex, reinterpret_cast<LPVOID>(TSD)));
+#elif SANITIZER_ANDROID
   *get_android_tls_ptr() = reinterpret_cast<uptr>(TSD);
 #elif SANITIZER_LINUX
   CurrentTSD = TSD;
 #else
   CHECK_EQ(pthread_setspecific(PThreadKey, reinterpret_cast<void *>(TSD)), 0);
 #endif  // SANITIZER_ANDROID
 }
 
+#if SANITIZER_WINDOWS
+static BOOL CALLBACK handleInit(PINIT_ONCE InitOnce, PVOID Parameter,
+                                PVOID *Context) {
+  initOnce();
+  return TRUE;
+}
+#endif
+
 void initThread(bool MinimalInit) {
+#if SANITIZER_WINDOWS
+  CHECK(InitOnceExecuteOnce(&InitOnce, handleInit, nullptr, nullptr));
+#else
   pthread_once(&GlobalInitialized, initOnce);
+#endif
   // Initial context assignment is done in a plain round-robin fashion.
   u32 Index = atomic_fetch_add(&CurrentIndex, 1, memory_order_relaxed);
   setCurrentTSD(&TSDs[Index % NumberOfTSDs]);
 }
 
 ScudoTSD *getTSDAndLockSlow(ScudoTSD *TSD) {
   if (NumberOfTSDs > 1) {
     // Use the Precedence of the current TSD as our random seed. Since we are in

compiler-rt/lib/scudo/scudo_tsd_shared.inc

 //===----------------------------------------------------------------------===//
 
 #ifndef SCUDO_TSD_H_
 # error "This file must be included inside scudo_tsd.h."
 #endif  // SCUDO_TSD_H_
 
 #if !SCUDO_TSD_EXCLUSIVE
 
+#if SANITIZER_WINDOWS
+extern DWORD TlsIndex;
+#elif !SANITIZER_ANDROID
 extern pthread_key_t PThreadKey;
+#endif
 
 #if SANITIZER_LINUX && !SANITIZER_ANDROID
 __attribute__((tls_model("initial-exec")))
 extern THREADLOCAL ScudoTSD *CurrentTSD;
 #endif
 
 ALWAYS_INLINE ScudoTSD* getCurrentTSD() {
-#if SANITIZER_ANDROID
+#if SANITIZER_WINDOWS
+  return reinterpret_cast<ScudoTSD *>(TlsGetValue(TlsIndex));
+#elif SANITIZER_ANDROID
   return reinterpret_cast<ScudoTSD *>(*get_android_tls_ptr());
 #elif SANITIZER_LINUX
   return CurrentTSD;
 #else
   return reinterpret_cast<ScudoTSD *>(pthread_getspecific(PThreadKey));
 #endif  // SANITIZER_ANDROID
 }
 

compiler-rt/test/scudo/cxx_threads.cpp

+// RUN: %clangxx_scudo %s -o %t
+// RUN: %env_scudo_opts="QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0"     %run %t 5 1000000 2>&1
+// RUN: %env_scudo_opts="QuarantineSizeKb=1024:ThreadLocalQuarantineSizeKb=64" %run %t 5 1000000 2>&1
+
+// Tests parallel allocations and deallocations of memory chunks from a number
+// of concurrent threads, with and without quarantine.
+// This test passes if everything executes properly without crashing.
+
+#include <assert.h>
+#include <condition_variable>
+#include <stdio.h>
+#include <stdlib.h>
+#include <thread>
+
+#include <sanitizer/allocator_interface.h>
+
+int num_threads;
+int total_num_alloc;
+const int kMaxNumThreads = 500;
+std::thread thread[kMaxNumThreads];
+
+std::condition_variable cond;
+std::mutex mutex;
+char go = 0;
+
+void *thread_fun(void *arg) {
+  mutex.lock();
+  while (!go) {
+    std::unique_lock<std::mutex> lk(mutex);
+    cond.wait(lk);
+  }
+
+  mutex.unlock();
+  for (int i = 0; i < total_num_alloc / num_threads; i++) {
+    void *p = malloc(10);
+    __asm__ __volatile__(""
+                         :
+                         : "r"(p)
+                         : "memory");
+    free(p);
+  }
+  return 0;
+}
+
+int main(int argc, char **argv) {
+  assert(argc == 3);
+  num_threads = atoi(argv[1]);
+  assert(num_threads > 0);
+  assert(num_threads <= kMaxNumThreads);
+  total_num_alloc = atoi(argv[2]);
+  assert(total_num_alloc > 0);
+
+  printf("%d threads, %d allocations in each\n", num_threads,
+         total_num_alloc / num_threads);
+  fprintf(stderr, "Heap size before: %zd\n", __sanitizer_get_heap_size());
+  fprintf(stderr, "Allocated bytes before: %zd\n",
+          __sanitizer_get_current_allocated_bytes());
+
+  mutex.lock();
+  for (int i = 0; i < num_threads; i++)
+    thread[i] = std::thread(thread_fun, (void *)0);
+  go = 1;
+  cond.notify_all();
+  mutex.unlock();
+  for (int i = 0; i < num_threads; i++)
+    thread[i].join();
+
+  fprintf(stderr, "Heap size after: %zd\n", __sanitizer_get_heap_size());
+  fprintf(stderr, "Allocated bytes after: %zd\n",
+          __sanitizer_get_current_allocated_bytes());
+
+  return 0;
+}

compiler-rt/test/scudo/dealloc-race.c

+// UNSUPPORTED: windows
+
 // RUN: %clang_scudo %s -O2 -o %t
 // RUN: %env_scudo_opts="QuarantineChunksUpToSize=0" %run %t 2>&1
 
 // This test attempts to reproduce a race condition in the deallocation path
 // when bypassing the Quarantine. The old behavior was to zero-out the chunk
 // header after checking its checksum, state & various other things, but that
 // left a window during which 2 (or more) threads could deallocate the same
 // chunk, with a net result of having said chunk present in those distinct

compiler-rt/test/scudo/fsanitize.c

 // Test various -fsanitize= additional flags combinations.
 
+// UNSUPPORTED: windows
+
 // RUN: %clang_scudo %s -o %t
 // RUN: not %run %t 2>&1 | FileCheck %s
 
 // RUN: %clang_scudo -shared-libsan %s -o %t
 // RUN: env LD_LIBRARY_PATH=`dirname %shared_libscudo`:$LD_LIBRARY_PATH not %run %t 2>&1 | FileCheck %s
 // RUN: %clang_scudo -shared-libsan -fsanitize-minimal-runtime %s -o %t
 // RUN: env LD_LIBRARY_PATH=`dirname %shared_minlibscudo`:$LD_LIBRARY_PATH not %run %t 2>&1 | FileCheck %s
 

compiler-rt/test/scudo/interface.cpp

 // RUN: %clangxx_scudo %s -lstdc++ -o %t
 // RUN:                                                   %run %t ownership          2>&1
 // RUN:                                                   %run %t ownership-and-size 2>&1
 // RUN:                                                   %run %t heap-size          2>&1
 // RUN: %env_scudo_opts="allocator_may_return_null=1"     %run %t soft-limit         2>&1
 // RUN: %env_scudo_opts="allocator_may_return_null=1" not %run %t hard-limit         2>&1
 
 // Tests that the sanitizer interface functions behave appropriately.
 
 #include <stdlib.h>
 #include <assert.h>
 #include <string.h>
+#if defined(_WIN32)
+#include <windows.h>
+#else
 #include <unistd.h>
+#endif
 
 #include <vector>
 
 #include <sanitizer/allocator_interface.h>
 #include <sanitizer/scudo_interface.h>
 
+#if defined(_MSC_VER)
+#include <BaseTsd.h>
+typedef SSIZE_T ssize_t;
+#endif
+
+void sleep_ms(unsigned int ms) {
+#if defined(_WIN32)
+  Sleep(ms);
+#else
+  usleep(ms * 1000U);
+#endif
+}
+
 int main(int argc, char **argv)
 {
   assert(argc == 2);
 
   if (!strcmp(argv[1], "ownership")) {
     // Ensures that __sanitizer_get_ownership can be called before any other
     // allocator function, and that it behaves properly on a pointer not owned
     // by us.
if (!strcmp(argv[1], "soft-limit")) {
     size_t size = 1 << 19;  // 512Kb
     for (int i = 0; i < 5; i++) {
       void *p = malloc(size);
       memset(p, 0, size);
       pointers.push_back(p);
     }
     // Set the soft RSS limit to 1Mb.
     __scudo_set_rss_limit(1, 0);
-    usleep(20000);
+    sleep_ms(200);
     // The following allocation should return NULL.
     void *p = malloc(size);
     assert(!p);
     // Remove the soft RSS limit.
     __scudo_set_rss_limit(0, 0);
     // The following allocation should succeed.
     p = malloc(size);
     assert(p);
if (!strcmp(argv[1], "hard-limit")) {
     size_t size = 1 << 19;  // 512Kb
     for (int i = 0; i < 5; i++) {
       void *p = malloc(size);
       memset(p, 0, size);
       pointers.push_back(p);
     }
     // Set the hard RSS limit to 1Mb
     __scudo_set_rss_limit(1, 1);
-    usleep(20000);
+    sleep_ms(200);
     // The following should trigger our death.
     void *p = malloc(size);
   }
 
   return 0;
 }

compiler-rt/test/scudo/lit.cfg.py

 # Path to the shared library
 shared_libscudo = os.path.join(config.compiler_rt_libdir, "libclang_rt.scudo%s.so" % config.target_suffix)
 shared_minlibscudo = os.path.join(config.compiler_rt_libdir, "libclang_rt.scudo_minimal%s.so" % config.target_suffix)
 
 # Test suffixes.
 config.suffixes = ['.c', '.cpp', '.test']
 
 # C & CXX flags.
 c_flags = ([config.target_cflags] +
-           ["-pthread",
+           ["-O0",
+            "-UNDEBUG"])
+
+if config.host_os != 'Windows':
+  c_flags += ["-pthread",
               "-fPIE",
               "-pie",
-           "-O0",
-           "-UNDEBUG",
               "-ldl",
-           "-Wl,--gc-sections"])
-
+              "-Wl,--gc-sections"]
   # Android doesn't want -lrt.
   if not config.android:
     c_flags += ["-lrt"]
 
-cxx_flags = (c_flags + config.cxx_mode_flags + ["-std=c++11"])
+cxx_flags = (c_flags + config.cxx_mode_flags)
+if config.host_os != 'Windows':
+  cxx_flags += ["-std=c++11"]
 
 scudo_flags = ["-fsanitize=scudo"]
 
 def build_invocation(compile_flags):
   return " " + " ".join([config.clang] + compile_flags) + " "
 
 # Add substitutions.
 config.substitutions.append(("%clang ", build_invocation(c_flags)))
if config.gwp_asan:
   config.environment['GWP_ASAN_OPTIONS'] = 'Enabled=0'
 
 if default_scudo_opts:
   config.environment['SCUDO_OPTIONS'] = default_scudo_opts
   default_scudo_opts += ':'
 config.substitutions.append(('%env_scudo_opts=',
                              'env SCUDO_OPTIONS=' + default_scudo_opts))
 
-# Hardened Allocator tests are currently supported on Linux only.
-if config.host_os not in ['Linux']:
+# Hardened Allocator tests are currently supported on Linux and Windows only.
+if config.host_os not in ['Linux', 'Windows']:
    config.unsupported = True

compiler-rt/test/scudo/malloc.cpp

 // RUN: %clangxx_scudo %s -lstdc++ -o %t
 // RUN: %run %t 2>&1
 
 // Tests that a regular workflow of allocation, memory fill and free works as
 // intended. Tests various sizes serviced by the primary and secondary
 // allocators.
 
 #include <assert.h>
 #include <stdlib.h>
 #include <string.h>
 
 #include <vector>
 
+#if defined(_MSC_VER)
+#include <BaseTsd.h>
+typedef SSIZE_T ssize_t;
+#endif
+
 int main(int argc, char **argv)
 {
   void *p;
   std::vector<ssize_t> sizes{1, 8, 16, 32, 1024, 32768,
     1 << 16, 1 << 17, 1 << 20, 1 << 24};
   std::vector<int> offsets{1, 0, -1, -7, -8, -15, -16, -31, -32};
 
   p = malloc(0);

compiler-rt/test/scudo/memalign.c

 // RUN: %clang_scudo %s -o %t
 // RUN:                                                 %run %t valid       2>&1
 // RUN:                                             not %run %t invalid     2>&1 | FileCheck --check-prefix=CHECK-align %s
 // RUN: %env_scudo_opts=allocator_may_return_null=1     %run %t invalid     2>&1
 // RUN:                                             not %run %t double-free 2>&1 | FileCheck --check-prefix=CHECK-double-free %s
 // RUN: %env_scudo_opts=DeallocationTypeMismatch=1  not %run %t realloc     2>&1 | FileCheck --check-prefix=CHECK-realloc %s
 // RUN: %env_scudo_opts=DeallocationTypeMismatch=0      %run %t realloc     2>&1
+// UNSUPPORTED: windows
 
 // Tests that the various aligned allocation functions work as intended. Also
 // tests for the condition where the alignment is not a power of 2.
 
 #include <assert.h>
 #include <errno.h>
 #include <malloc.h>
 #include <stdint.h>

compiler-rt/test/scudo/mismatch.cpp

if (!strcmp(argv[1], "newfree")) {
     int *p = new int;
     assert(p);
     free((void *)p);
   }
   return 0;
 }
 
 // CHECK-dealloc: ERROR: allocation type mismatch when deallocating address
-// CHECK-realloc: ERROR: allocation type mismatch when reallocating address

compiler-rt/test/scudo/overflow.c

 // RUN: %clang_scudo %s -o %t
 // RUN:                                     not %run %t malloc     2>&1 | FileCheck %s
 // RUN: %env_scudo_opts=QuarantineSizeKb=64 not %run %t quarantine 2>&1 | FileCheck %s
 
 // Tests that header corruption of an allocated or quarantined chunk is caught.
 
 #include <assert.h>
 #include <stdlib.h>
 #include <string.h>
 
+#if defined(_MSC_VER)
+#include <BaseTsd.h>
+typedef SSIZE_T ssize_t;
+#endif
+
 int main(int argc, char **argv)
 {
   ssize_t offset = sizeof(void *) == 8 ? 8 : 0;
 
   assert(argc == 2);
 
   if (!strcmp(argv[1], "malloc")) {
     // Simulate a header corruption of an allocated chunk (1-bit)

compiler-rt/test/scudo/preload.cpp

 // Test that the preloaded runtime works without linking the static library.
 
 // RUN: %clang %s -lstdc++ -o %t
 // RUN: env LD_PRELOAD=%shared_libscudo    not %run %t 2>&1 | FileCheck %s
 // RUN: env LD_PRELOAD=%shared_minlibscudo not %run %t 2>&1 | FileCheck %s
 
 // This way of setting LD_PRELOAD does not work with Android test runner.
-// REQUIRES: !android
+// UNSUPPORTED: android, windows
 
 #include <assert.h>
 
 int main(int argc, char *argv[]) {
   int *p = new int;
   assert(p);
   *p = 0;
   delete p;
   delete p;
   return 0;
 }
 
 // CHECK: ERROR: invalid chunk state

compiler-rt/test/scudo/rss.c

 // with a high limit, the test should pass without any malloc returning NULL or
 // the program dying.
 // If a limit is specified, it should return some NULL or die depending on
 // allocator_may_return_null. This should also work without statm.
 
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#if defined(_WIN32)
+#include <windows.h>
+#else
 #include <unistd.h>
+#endif
 
 static const size_t kNumAllocs = 64;
 static const size_t kAllocSize = 1 << 20;  // 1MB.
 
 static void *allocs[kNumAllocs];
 
+void sleep_ms(unsigned int ms) {
+#if defined(_WIN32)
+  Sleep(ms);
+#else
+  usleep(ms * 1000U);
+#endif
+}
+
 int main(int argc, char *argv[]) {
   int returned_null = 0;
   for (int i = 0; i < kNumAllocs; i++) {
     // sleep for 100ms every 8 allocations, to allow the RSS check to catch up.
     if (i != 0 && (i & 0x7) == 0)
-      usleep(100000);
+      sleep_ms(100);
     allocs[i] = malloc(kAllocSize);
     if (allocs[i])
       memset(allocs[i], 0xff, kAllocSize);  // Dirty the pages.
     else
       returned_null++;
   }
   for (int i = 0; i < kNumAllocs; i++)
     free(allocs[i]);

compiler-rt/test/scudo/secondary.c

 // RUN: %clang_scudo %s -o %t
 // RUN: %run %t after  2>&1 | FileCheck %s
 // RUN: %run %t before 2>&1 | FileCheck %s
 
 // Test that we hit a guard page when writing past the end of a chunk
 // allocated by the Secondary allocator, or writing too far in front of it.
 
 #include <assert.h>
-#include <malloc.h>
-#include <signal.h>
+#include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#ifdef _WIN32
+#include <windows.h>
+#else
+#include <signal.h>
 #include <unistd.h>
+#endif
 
+#ifdef _WIN32
+DWORD getsystempagesize() {
+  SYSTEM_INFO si;
+  GetSystemInfo(&si);
+  return si.dwPageSize;
+}
+LONG WINAPI handler(EXCEPTION_POINTERS *ExceptionInfo) {
+  fprintf(stderr, "AccessViolation\n");
+  ExitProcess(0);
+}
+#else
 void handler(int signo, siginfo_t *info, void *uctx) {
   if (info->si_code == SEGV_ACCERR) {
-    fprintf(stderr, "SCUDO SIGSEGV\n");
+    fprintf(stderr, "AccessViolation\n");
     exit(0);
   }
   exit(1);
 }
+long getsystempagesize() {
+  return sysconf(_SC_PAGESIZE);
+}
+#endif
 
 int main(int argc, char **argv)
 {
   // The size must be large enough to be serviced by the secondary allocator.
-  long page_size = sysconf(_SC_PAGESIZE);
-  size_t size = (1U << 17) + page_size;
-  struct sigaction a;
+  long page_size = getsystempagesize();
+  size_t size = (1U << 19) + page_size;
 
   assert(argc == 2);
-  memset(&a, 0, sizeof(a));
-  a.sa_sigaction = handler;
-  a.sa_flags = SA_SIGINFO;
 
   char *p = (char *)malloc(size);
   assert(p);
   memset(p, 'A', size); // This should not trigger anything.
   // Set up the SIGSEGV handler now, as the rest should trigger an AV.
+#ifdef _WIN32
+  SetUnhandledExceptionFilter(handler);
+#else
+  struct sigaction a = {0};
+  a.sa_sigaction = handler;
+  a.sa_flags = SA_SIGINFO;
   sigaction(SIGSEGV, &a, NULL);
+#endif
+
   if (!strcmp(argv[1], "after")) {
     for (int i = 0; i < page_size; i++)
       p[size + i] = 'A';
   }
   if (!strcmp(argv[1], "before")) {
     for (int i = 1; i < page_size; i++)
       p[-i] = 'A';
   }
   free(p);
 
   return 1; // A successful test means we shouldn't reach this.
 }
 
-// CHECK: SCUDO SIGSEGV
+// CHECK: AccessViolation

compiler-rt/test/scudo/symbols.test

-UNSUPPORTED: android
+UNSUPPORTED: android, windows
 
 Verify that various functions are *not* present in the minimal binary. Presence
 of those symbols in the minimal runtime would mean that the split code made it
 back into the core Sanitizer runtime library.
 
 RUN: nm %shared_minlibscudo | not grep Symbolizer
 RUN: nm %shared_minlibscudo | not grep Coverage

compiler-rt/test/scudo/threads.c

 // RUN: %clang_scudo %s -o %t
 // RUN: %env_scudo_opts="QuarantineSizeKb=0:ThreadLocalQuarantineSizeKb=0"     %run %t 5 1000000 2>&1
 // RUN: %env_scudo_opts="QuarantineSizeKb=1024:ThreadLocalQuarantineSizeKb=64" %run %t 5 1000000 2>&1
+// UNSUPPORTED: windows
 
 // Tests parallel allocations and deallocations of memory chunks from a number
 // of concurrent threads, with and without quarantine.
 // This test passes if everything executes properly without crashing.
 
 #include <assert.h>
 #include <pthread.h>
 #include <stdlib.h>

compiler-rt/test/scudo/tsd_destruction.c

 // RUN: %clang_scudo %s -o %t
 // RUN: %run %t 2>&1
+// UNSUPPORTED: windows
 
 #include <locale.h>
 #include <pthread.h>
 #include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
 // Some of glibc's own thread local data is destroyed after a user's thread

compiler-rt/test/scudo/valloc.c

 // RUN: %clang_scudo %s -o %t
 // RUN:                                                 %run %t valid   2>&1
 // RUN:                                             not %run %t invalid 2>&1 | FileCheck %s
 // RUN: %env_scudo_opts=allocator_may_return_null=1     %run %t invalid 2>&1
-// UNSUPPORTED: android
+// UNSUPPORTED: android, windows
 
 // Tests that valloc and pvalloc work as intended.
 
 #include <assert.h>
 #include <errno.h>
 #include <malloc.h>
 #include <stdint.h>
 #include <string.h>

llvm/cmake/modules/HandleLLVMOptions.cmake

if (LLVM_ON_UNIX)
     elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR
             LLVM_USE_SANITIZER STREQUAL "Undefined;Address")
       append_common_sanitizer_flags()
       append("-fsanitize=address" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
       append("${LLVM_UBSAN_FLAGS}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
     elseif (LLVM_USE_SANITIZER STREQUAL "Leaks")
       append_common_sanitizer_flags()
       append("-fsanitize=leak" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+    elseif (LLVM_USE_SANITIZER STREQUAL "Scudo")
+      append_common_sanitizer_flags()
+      append("-fsanitize=scudo" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
     else()
       message(FATAL_ERROR "Unsupported value of LLVM_USE_SANITIZER: ${LLVM_USE_SANITIZER}")
     endif()
   elseif(MSVC)
     if (LLVM_USE_SANITIZER STREQUAL "Address")
       append_common_sanitizer_flags()
       append("-fsanitize=address" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
     else()

llvm/lib/Support/CMakeLists.txt

 if(LLVM_INTEGRATED_CRT_ALLOC)
   if (CMAKE_BUILD_TYPE AND NOT ${LLVM_USE_CRT_${uppercase_CMAKE_BUILD_TYPE}} MATCHES "^(MT|MTd)$")
     message(FATAL_ERROR "LLVM_INTEGRATED_CRT_ALLOC only works with /MT or /MTd. Use LLVM_USE_CRT_${uppercase_CMAKE_BUILD_TYPE} to set the appropriate option.")
   endif()
 
   string(REGEX REPLACE "(/|\\\\)$" "" LLVM_INTEGRATED_CRT_ALLOC "${LLVM_INTEGRATED_CRT_ALLOC}")
 
   if(NOT EXISTS "${LLVM_INTEGRATED_CRT_ALLOC}")
-    message(FATAL_ERROR "Cannot find the path to `git clone` for the CRT allocator! (${LLVM_INTEGRATED_CRT_ALLOC}). Currently, rpmalloc, snmalloc and mimalloc are supported.")
+    message(FATAL_ERROR "Cannot find the path to `git clone` for the CRT allocator! (${LLVM_INTEGRATED_CRT_ALLOC}). Currently, rpmalloc, snmalloc, mimalloc and scudo are supported.")
   endif()
 
   if(LLVM_INTEGRATED_CRT_ALLOC MATCHES "rpmalloc$")
     add_definitions(-DENABLE_OVERRIDE -DENABLE_PRELOAD)
     set(ALLOCATOR_FILES "${LLVM_INTEGRATED_CRT_ALLOC}/rpmalloc/rpmalloc.c")
   elseif(LLVM_INTEGRATED_CRT_ALLOC MATCHES "snmalloc$")
     set(ALLOCATOR_FILES "${LLVM_INTEGRATED_CRT_ALLOC}/src/override/malloc.cc" "${LLVM_INTEGRATED_CRT_ALLOC}/src/override/new.cc")
     set(system_libs ${system_libs} "mincore.lib" "-INCLUDE:malloc")
   elseif(LLVM_INTEGRATED_CRT_ALLOC MATCHES "mimalloc$")
     set(MIMALLOC_LIB "${LLVM_INTEGRATED_CRT_ALLOC}/out/msvc-x64/Release/mimalloc-static.lib")
     if(NOT EXISTS "${MIMALLOC_LIB}")
     message(FATAL_ERROR "Cannot find the mimalloc static library. To build it, first apply the patch from https://github.com/microsoft/mimalloc/issues/268 then build the Release x64 target through ${LLVM_INTEGRATED_CRT_ALLOC}\\ide\\vs2019\\mimalloc.sln")
     endif()
     set(system_libs ${system_libs} "${MIMALLOC_LIB}" "-INCLUDE:malloc")
+  elseif(LLVM_INTEGRATED_CRT_ALLOC MATCHES "scudo")
+    set(system_libs ${system_libs} "${LLVM_INTEGRATED_CRT_ALLOC}" "-INCLUDE:malloc")
   endif()
 endif()
 
 add_llvm_component_library(LLVMSupport
   AArch64TargetParser.cpp
   ABIBreak.cpp
   ARMTargetParser.cpp
   AMDGPUMetadata.cpp