[compiler-rt] r263160 - [Windows] Fix UnmapOrDie and MmapAlignedOrDie

[Reid Kleckner via llvm-commits]

On Mon, May 9, 2016 at 6:21 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
> Reid,
>
> How do you think we should fix it?

Does this problem only occur in CreateThreadContext? I would say, we
solve this by not overallocating and attempting to trim the
allocation, but then we have this comment:
  new((void*)hdr) Trace();
  // We are going to use only a small part of the trace with the default
  // value of history_size. However, the constructor writes to the whole trace.
  // Unmap the unused part.

Does Trace really need to be one giant object, or can we do something like this?

struct Trace {
  Mutex mtx;
  ...
  TraceHeader *getTrailingTraceHeaders() { return
reinterpret_cast<TraceHeader*>(this + 1); }
};

If so, then we can compute the size for MapThreadTrace up front and we
don't need to trim the allocation. That's probably good for Linux,
too, right?

I wanted to find a way to test building tsan on Windows, but from
lib/tsan/go/build.bat it looks like it only supports a unity-style
mingw gcc build, and then I can't run any tests without a go
implementation. There's no need to port tsan to build with MSVC, but
it would be nice if I could build and test it with mingw and cmake.