[PATCH] D23354: [compiler-rt] Support dynamic shadow address instrumentation

[Kostya Serebryany via llvm-commits]

kcc added a comment.

> We're not trying to support all versions of Windows. But a significant portion of our user population is still on Win7/8/8.1, and not on Win10. We'd like to support them for as long as Chrome supports those platforms.


Maybe that's not the right goal? 
Win7/8/8.1 tend to have slower machines and giving them asan-ified binaries *might* be a bad idea anyway.

> No matter what static address you choose, there's a non-zero chance that something else will be there. Especially since all sorts of things out of control (third party code) likes to inject itself into Chrome's address space. Since we're trying to grab 12.5% of the address space, that chance is actually pretty high.


I perfectly understand that, but I have no expertise to know if there is no way to workaround this. 
This is why I am asking someone from Microsoft to help.

> In a lab it's fine for occasional failures to start due to address space collisions. On a users machine, not so much. SyzyASAN chose a dynamic shadow for this reason. We're gearing up to ship 64-bit ASAN to the canary Windows users, and shipping a product that can randomly fail to start is simply not going to happen.


Of course.

> If the ability to run with a non-dynamic shadow is preserved as an instrumentation time choice, why can't we support both worlds?


We can. I am not convinced we've done everything to avoid it.

> If you really want to tweak out the last small slice of performance in a lab scenario then feel free to use a static shadow. For shipping to users where the ability to reliably start trumps performance, then use a dynamic shadow.


On the contrary. When testing Chrome in a lab, 10% of speed is "just" money. 
On a user machine it might be a difference between tolerable and intolerable UI speed. 
Same for binary size.


https://reviews.llvm.org/D23354