[MLton-devel] mlton on freebsd update

[Sam M. Rushing]

> -----Original Message-----
> From: Stephen Weeks [  <mailto:sweeks@sweeks.com>
mailto:sweeks@sweeks.com]
> Sent: Thursday, August 29, 2002 7:20 PM
> To: Sam M. Rushing
> Cc: MLton@mlton.org
> Subject: RE: [MLton-devel] mlton on freebsd
>
> > I wonder if we could skip the whole linux emulation issue if someone
> > could send me a tarball with the generated assembly?
>
> I put a tarball of the generated assembly for the latest experimental
> release (20020825) on the MLton files page at sourceforge:
>
>         <https://sourceforge.net/project/showfiles.php?group_id=50419>
https://sourceforge.net/project/showfiles.php?group_id=50419
>
> Grab mlton-20020825-1.C-and-asm.tgz.

Ok, was able to link those files without too much trouble. The resulting
'mlton-compile' behaved strangely, though - it would start up -
supposedly processing the basis library, and then it would 'hang',
waiting for some kind of input on stdin:
  bash-2.05a$ build/lib/mlton-compile basis-library world
  unhandled exception: Fail cannot close basis-library/bind-basis due to
error: badf: Bad file descriptor
  bash-2.05a$ build/lib/mlton-compile basis-library world
  1
  ;
  2;
  <ctrl-d>
  basis-library/1:1.0-1.0 Error: parse error
  unhandled exception: Fail cannot close basis-library/1 due to error:
badf: Bad file descriptor
  bash-2.05a$
  bash-2.05a$
I figured that the copied-asm-hack wasn't working because of some
incompatible constant between linux<=>freebsd, so I went back to
bootstrapping with sml/nj.
After a ~24hr compile (800MHz AMD/400MB RAM) I finally got a new version
of 'mlton-compile', but it behaves exactly the same way - it's waiting
for input on stdin.
A syscall trace shows a series of failed mmap() calls (I think that for
some reason freebsd mmap() is failing with the provided 'hint'
addresses) followed by a call to read():
 35263 mlton-compile RET   gettimeofday 0
 35263 mlton-compile CALL  munmap(0xb8000000,0x103000)
 35263 mlton-compile RET   munmap 0
 35263 mlton-compile CALL  munmap(0x2888e000,0x5f000)
 35263 mlton-compile RET   munmap 0
 35263 mlton-compile CALL
mmap(0xf8000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xf0000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xe8000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xe0000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xd8000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xd0000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xc8000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xc0000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1 errno 12 Cannot allocate memory
 35263 mlton-compile CALL
mmap(0xb8000000,0x522000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap -1207959552/0xb8000000
 35263 mlton-compile CALL  munmap(0x287e9000,0xa5000)
 35263 mlton-compile RET   munmap 0
 35263 mlton-compile CALL  munmap(0x287e5000,0x2000)
 35263 mlton-compile RET   munmap 0
 35263 mlton-compile CALL  mmap(0,0x6000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap 679383040/0x287e9000
 35263 mlton-compile CALL  mmap(0,0x6000,0x3,0x1002,0xffffffff,0,0,0)
 35263 mlton-compile RET   mmap 679407616/0x287ef000
 35263 mlton-compile CALL  munmap(0x287e7000,0x2000)
 35263 mlton-compile RET   munmap 0
 35263 mlton-compile CALL  getrusage(0,0xbfbffa40)
 35263 mlton-compile RET   getrusage 0
 35263 mlton-compile CALL  getrusage(0,0xbfbff948)
 35263 mlton-compile RET   getrusage 0
 35263 mlton-compile CALL  getrusage(0xffffffff,0xbfbff948)
 35263 mlton-compile RET   getrusage 0
 35263 mlton-compile CALL  gettimeofday(0xbfbff940,0)
 35263 mlton-compile RET   gettimeofday 0
 35263 mlton-compile CALL  sigprocmask(0x2,0x879e240,0)
 35263 mlton-compile RET   sigprocmask 0
 35263 mlton-compile CALL  read(0x1,0xb80b0ed0,0x1000) <I hit ctrl-d
here>
 35263 mlton-compile GIO   fd 1 read 0 bytes
 
I don't think the failing mmap() calls are critical, because I get the
same result if I used "fixed-heap 200m":
 
 35275 mlton-compile CALL  getrusage(0xffffffff,0xbfbff920)
 35275 mlton-compile RET   getrusage 0
 35275 mlton-compile CALL  gettimeofday(0xbfbff918,0)
 35275 mlton-compile RET   gettimeofday 0
 35275 mlton-compile CALL  sigprocmask(0x2,0x879e240,0)
 35275 mlton-compile RET   sigprocmask 0
 35275 mlton-compile CALL  read(0x1,0xb010fc68,0x1000)
 35275 mlton-compile GIO   fd 1 read 0 bytes
Is there something I'm missing, perhaps a secret code phrase? 8^)
I tried compiling a few files from the 'regression' directory, all seem
to work just fine.
-Sam
 


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel