[MLton] Cygwin, file open, and reserveEsp

Stephen Weeks MLton@mlton.org
Fri, 19 Dec 2003 19:05:18 -0800

I've made some progress on the Cygwin problem that has been around for
months.  To recap: building MLton fails on Cygwin, due to a call to
open failing when trying to write the world file.  Anoq sent a helpful
mail detailing all the things that can go wrong with the arguments to
open.  I've checked those out, and they don't seem to be the problem.

With debugging messages on, here's the call that's failing.

-1 = Posix_FileSys_open (/tmp/package-mlton-cygwin/build/lib/world.mlton, 0x00010601, 0x000001b6)

The flags 0x00010601 is the logical or of the following
	O_BINARY = 0x00010000
	O_CREATE = 0x00000200
	O_TRUNC = 0x00000400
	O_WRONLY = 0x00000001

The mode 0x000001B6 is the logical or of the following
	S_IRUSR = 0x00000100
	S_IWUSR = 0x00000080
	S_IRGRP = 0x00000020
	S_IWGRP = 0x00000010
	S_IROTH = 0x00000004
	S_IWOTH = 0x00000002

So, that all looks OK.

I wondered if the problem could be a code generator bug, so I tried
the build with -native false.  That worked fine.  Then, since things
work on x86/Linux, I wondered if the problem had anything to do with
reserveEsp, which is the only difference in how the codegen behaves
between Cygwin and Linux.  Surprisingly, by setting reserveEsp to
false, MLton builds fine on Cygwin and passes all the regressions
(that it usually does on Cygwin) except for those that use signals:
mutex, prodcons, thread2, timeout.  By setting reserveEsp to true, all
the signal regressions are fine.

So, it looks like on Cygwin we no longer need reserveEsp, except for
programs that handle signals.  I have changed the default, and added
an expert flag, -reserve-esp {false|true}, that will let us experiment
with it.

Here are a couple more facts.  Self compiles and all the regressions
are fine on Linux with both reserveEsp = true and reserveEsp = false.
All the regressions are fine on Cygwin with reserveEsp = true.

In summary the only failure is a self compile on Cygwin with
reserveEsp = true.  Since there is no similar failure on Linux, that
makes it less likely that it is a native codegen bug.  But maybe there
is some bug that is only triggered due to Cygwin weirdness.  Any