This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Performance optimization in av::fixup - use buffered IO, not mapped file


On 10/12/2012 10:51 PM, Daniel Colascione wrote:
On 12/10/2012 6:32 PM, Ryan Johnson wrote:
On 10/12/2012 8:41 PM, Daniel Colascione wrote:
On 12/10/2012 5:36 PM, Ryan Johnson wrote:
I never reported it because I figured there was no way cygwin could make Windows
decide what files to cache or not cache... but it would definitely be nice to
see the problem go away.
This behavior is definitely surprising. It's sort of an evil-genie way to
provide cache coherency, I suppose.

Now, if we run emacs.exe from cmd, not bash, that's exactly what happens:
<snip>
I came up with a simple test case that reproduces in cmd the behavior I see
when
I run Emacs from bash. I've reproduced the program below. Here, I've compiled
a.exe with -DSLOW:
I tried to test on my machine (w7 x64), but I can't get it to compile
(GetFileSizeEx not found at link time):

i686-pc-mingw32-gcc emacs-slow.c -DSLOW -lkernel32
I just used i686-w64-mingw32-gcc. I didn't even need -lkernel32.
OK, that compiles, but I can't repro:
I can't repro it with the stock emacs-nox or emacs-X11 either, even as
administrator. But I can consistently repro it with any Emacs I build. More
bizarrely, if I take an emacs binary I've build and hardlink it into /bin, I can
repro the problem. If I _copy_ the binary instead of hardlinking it, I can't
repro, even though the copy has the same hard link count and ACL as the
hardlinked version.

The key to generating a binary that repros the problem is to unexec emacs, then
try to repro with that generated binary, not a copy of it. Maybe the process of
modifying the binary during unexec borks the system's ASLR cache; I can't
reproduce the problem with a simple testcase that copies and modifies the
binary, but my test doesn't actually change the binary --- it just writes back
to the destination binary exactly what we read from it.
That doesn't explain why gcc stage1/2 compilers (in ./xgcc) would have the problem. At least, I don't think gcc self-modifies when invoked from ./configure...

But you're right. Once the compiler has been officially installed somewhere (not necessarily /usr/bin) it runs normally. Very weird.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]