drcachesim: add Windows support #1727

Open
derekbruening opened this Issue Jul 7, 2015 · 5 comments

Comments

Projects
None yet
1 participant
@derekbruening
Contributor

derekbruening commented Jul 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@derekbruening

derekbruening Sep 20, 2016

Contributor

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%
Contributor

derekbruening commented Sep 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@derekbruening

derekbruening Sep 21, 2016

Contributor

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.

Contributor

derekbruening commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@derekbruening

derekbruening Sep 21, 2016

Contributor

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

Contributor

derekbruening commented Sep 21, 2016

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

@derekbruening

This comment has been minimized.

Show comment
Hide comment
@derekbruening

derekbruening Sep 21, 2016

Contributor

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

Contributor

derekbruening commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@derekbruening

derekbruening Sep 21, 2016

Contributor

Single-process support is in:

  • 07093c3 #975 static DR: Windows static client support
  • 7888817 #1727 drcachesim Windows: implement named pipes and fix build issues
  • e510cc7 #1727 drcachesim Windows: enable drcachesim tests on Windows

Leaving open for multi-process support.

Contributor

derekbruening commented Sep 21, 2016

Single-process support is in:

  • 07093c3 #975 static DR: Windows static client support
  • 7888817 #1727 drcachesim Windows: implement named pipes and fix build issues
  • e510cc7 #1727 drcachesim Windows: enable drcachesim tests on Windows

Leaving open for multi-process support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment