drcachesim: add Windows support

[derekbruening]

Split from #1703

This issue covers adding Windows support to drcachesim. Primarily this means implementing named pipe support for Windows. If Windows named pipes cannot handle multiple writers, the IPC setup in drcachesim may need to be tweaked to merge multiple pipes in the reader.

[derekbruening]

It seems best to quickly fix this now so that all the future offline stuff will be tested. The sooner this is added the less work later.

*** TODO /MT vs /MTd build issues due to sharing files bet client and exe

Windows build issue: source files used in both tracer client and drcachesim
exe end up with two sets of compile flags, sometimes conflicting.
Plus, libcmtd.lib is linked in, I think due to drinjectlib. This means we
have to override all the /MT (incl on sources instead of targets, for
client-shared files) with /MTd.

*** TODO vastly different simulator output

Linux:

Core #0 (1 thread(s))
  L1I stats:
    Hits:                          161,055
    Misses:                            779
    Miss rate:                        0.48%
  L1D stats:
    Hits:                           71,240
    Misses:                          1,436
    Miss rate:                        1.98%
Core #1 (0 thread(s))
Core #2 (0 thread(s))
Core #3 (0 thread(s))
LL stats:
    Hits:                              227
    Misses:                          1,988
    Local miss rate:                 89.75%
    Child hits:                    232,295
    Total miss rate:                  0.85%

Windows is running a lot more code (CRT or STL differences presumably):

Core #0 (1 thread(s))
  L1I stats:
    Hits:                        3,120,189
    Misses:                          1,254
    Miss rate:                        0.04%
  L1D stats:
    Hits:                          601,612
    Misses:                         29,730
    Miss rate:                        4.71%
Core #1 (0 thread(s))
Core #2 (0 thread(s))
Core #3 (0 thread(s))
LL stats:
    Hits:                            1,056
    Misses:                         29,928
    Local miss rate:                 96.59%
    Child hits:                  3,721,801
    Total miss rate:                  0.80%

[derekbruening]

I have the named pipe working on Windows except for one problem: a child process fails to open a write handle to it. CreateFileA fails with ERROR_INVALID_PARAMETER in the child process.

I have yet to figure this out. Changing the CreateProcess to inherit handles (shouldn't matter): no difference. Removing the sharing flags: no difference. The pipe name is the same as the client in the parent. I plan to go ahead and put in the rest of the changes to get base Windows testing in place for future offline trace work and we'll figure this out later.

[derekbruening]

I also never figured out the atomic pipe write limit on Windows. I'm sticking with 512 from POSIX.1-2001.

[derekbruening]

It turns out that it is complex to support multiple processes connecting to a named pipe:

    // FIXME i#1727: support multiple processes.  We get ERROR_PIPE_BUSY if
    // a 2nd process connects to the same pipe instance, so we need an array
    // of instances (we'll have to set a maximum) and to use overlapped i/o
    // and have read() wait on an event for each pipe instance (or, use a
    // separate thread per app process, but that significantly changes our
    // design).

See the example at https://msdn.microsoft.com/en-us/library/windows/desktop/aa365603(v=vs.85).aspx

[derekbruening]

Single-process support is in:

• 07093c3 re-add support for building as a static library #975 static DR: Windows static client support
• 7888817 drcachesim: add Windows support #1727 drcachesim Windows: implement named pipes and fix build issues
• e510cc7 drcachesim: add Windows support #1727 drcachesim Windows: enable drcachesim tests on Windows

Leaving open for multi-process support.