[MLton] Question on Investigating Segfaults in Compiler

Brent Fulgham bfulg@pacbell.net
Thu, 8 Jul 2004 09:23:51 -0700 (PDT)

I decided to take a stab at generating a MLton
executable  free of the Cygwin compatibility layer.  I
know Johnny (Anoq) has done this before in the past,
though via a bit of a tortuous route (see
http://www.hardcoreprocessing.com for details).

For better or worse, what I did was as follows:

1.  Modified the upgrade-basis script to include a new
term (Mingwin).
2.  Modified the 'platform' script to understand the
MINGW environment.
3.  Modified a host of Runtime sources to do
Win32-specific stuff where possible.  Luckily the GC
has already been modified in this way.
4.  I rebuilt MLton under Cygwin with my new basis
(that included the Mingwin terms), then copied this
over to my MINGW environment and verified it could
build test programs.
5.  I then did a "make all-no-docs" and corrected a
bunch of typo's I had made in the runtime modules, and
watched as everything linked properly.
6.  The make process then segfaults while trying to
build the basis library.

(gdb) run @MLton --
Starting program:
@MLton -- /c/fulgham/projects/mlton/build/lib/world

Program received signal SIGSEGV, Segmentation fault.
0x00558244 in Chunk199 () at mlton.199.c:5997
5997            Raise ();
(gdb) bt
#0  0x00558244 in Chunk199 () at mlton.199.c:5997
#1  0x02983370 in ?? ()
(gdb) Cannot access memory at address 0x14e
5992            Push (152);
5993            FarJump (7, 48242);
5994    default:
5995    L_319561:
5996            GPNR(0) = G(Pointer, 4443);
5997            Raise ();
5998    }
5999    case 6353:
6000            Push (-156);
6001            S(Pointer, 152) = S(Pointer, 156);

I suspect that some aspect of the runtime changes I
made is causing this, but I'm not sure how to map the
generated C code to the offending piece of the runtime

Any recommendations on how to backtrack from here?