[MLton] Progress on AMD64/FreeBSD

Jesper Louis Andersen jesper.louis.andersen at gmail.com
Sat Jun 23 11:43:46 PDT 2007 

On 6/23/07, Matthew Fluet <fluet at tti-c.org> wrote:
>
> Jesper Louis Andersen wrote:
> > The runtime only required a single change to be ported.
>
> Great!


Indeed! I have run into a runtime problem in the mean time, but I'll explain
that later. I wont be able to look at fully until after the 28th but if
anybody
has suggestions to do something about this, I'll gladly hear about it.

I am not yet sure if we are denied the allocation size we try to map. I will
check that
when I get some time. I have a hunch this might be the case as FreeBSD
generally
has limits on such things.

I opted for bootstrapping 2a). Only thing i needed to change was
"target map" --> "targetmap" and to copy mllex/mlyacc over as
well. I also needed a 32bit version of libGMP, but that was expected.

I use the following crude shell script
---
#!/bin/sh



#gmake
clean
gmake dirs
runtime
cp build.bak/lib/mlton-compile
build/lib
cp build.bak/bin/mllex
build/bin
cp build.bak/bin/mlyacc
build/bin
gmake world-no-check script mlbpathmap targetmap constants libraries
tools
gmake
compiler
gmake world
---

Current diff follows. I maintain an off-tree in git (Linus Torvalds SCM
system) which is tied to MLton SVN
through a conduit program, git-svn. The advantage is that branches are
actually easy to work with in
git, compared to SVN. However, I found the learning curve to be quite steep.

Some notes:
* Teach bin/platform to understand amd64 as a HOST_ARCH on FreeBSD

* Teach the ''catcher'' that we are a 64-bit arch by adopting the same
scheme as in the linux port

* It is wrong for the sysctl to return an int now. We get an ENOMEM from
sysctl since the
physmem doesn't necessarily fit in a 32-bit value. I hope size_t is enough
and correct and works
on x86 as well.

However, this is not enough! Our runtime enters an infinite loop on the
heap-allocation for any
program. I instrumented mllex with a debug runtime and added some printfs
since I couldn't figure
out the maze in the C code for adding DEBUG of the GC.

We are looping with:

ogre% ./build/bin/mllex | head -n 60
physMem: 1061425152
Couldn't map 0, 94208
Couldn't map f8000000, 94208
Couldn't map f0000000, 94208
Couldn't map e8000000, 94208
Couldn't map e0000000, 94208
Couldn't map d8000000, 94208
Couldn't map d0000000, 94208
Couldn't map c8000000, 94208
Couldn't map c0000000, 94208
Couldn't map b8000000, 94208
Couldn't map b0000000, 94208
Couldn't map a8000000, 94208
Couldn't map a0000000, 94208
Couldn't map 98000000, 94208
Couldn't map 90000000, 94208
Couldn't map 88000000, 94208
Couldn't map 80000000, 94208
Couldn't map 78000000, 94208
Couldn't map 70000000, 94208
Couldn't map 68000000, 94208
Couldn't map 60000000, 94208
Couldn't map 58000000, 94208
Couldn't map 50000000, 94208
Couldn't map 48000000, 94208
Couldn't map 40000000, 94208
Couldn't map 38000000, 94208
Couldn't map 30000000, 94208
Couldn't map 28000000, 94208
Couldn't map 20000000, 94208
Couldn't map 18000000, 94208
Couldn't map 10000000, 94208
Couldn't map 8000000, 94208
Couldn't map 0, 94208
Couldn't map f8000000, 94208
Couldn't map f0000000, 94208
Couldn't map e8000000, 94208
...

Where I instrumented a print of the address and size of the failing mmap()
call inside
the code. GDB:

Breakpoint 1, 0x000000003813e5c0 in mmap () from /lib/libc.so.6
(gdb) bt
#0  0x000000003813e5c0 in mmap () from /lib/libc.so.6
#1  0x000000000044bb4f in mmapAnon (start=0xf7fffffff8000000,
    length=94208) at platform/mmap.c:2
#2  0x000000000044bb29 in GC_mmapAnon (
    start=0xf7fffffff8000000, length=94208)
    at platform/use-mmap.c:12
#3  0x00000000004453d4 in createHeap (s=0x2c68, h=0x567308,
    desiredSize=17870283321271910400, minSize=5658496)
    at gc/heap.c:184
#4  0x0000000000446039 in initWorld (s=0x566f20)
    at gc/init-world.c:144
#5  0x0000000000446e56 in GC_init (s=0x566f20, argc=1, argv=0x1)
    at gc/init.c:334
#6  0x000000000044b3fe in MLton_init (argc=1,
    argv=0x7fffffffe598, s=0xf7fffffff8000000) at platform.c:20
#7  0x0000000000402ed8 in main (argc=-134217728, argv=0x17000)
    at /tmp/file0NuI7N.3.c:1562
(gdb) down
#3  0x00000000004453d4 in createHeap (s=0x2c68, h=0x567308,
    desiredSize=17870283321271910400, minSize=5658496)
    at gc/heap.c:184
184           h->start = GC_mmapAnon ((pointer)address, h->size);
(gdb) print address
$1 = 17870283321271910400
(gdb) print h->size
$2 = 94208

ogre% git-branch
  freebsd-fix-runtime-bugs
* freebsd-port-branch
  master
  mlton-2005
  mlton-trunk
  port-amd64-freebsd
  ssa-tree-cleanup

git-log -20 output:
commit 467cdf0a4b20f6913838aa7e0e78da949f03c09b
Author: Jesper Louis Andersen <jesper.louis.andersen at gmail.com>
Date:   Sat Jun 23 21:15:22 2007 +0200

    Get rid of #include <assert.h> again.

commit f3ba5ec5d8d65a319ed419d79b837c054e35d281
Author: Jesper Louis Andersen <jesper.louis.andersen at gmail.com>
Date:   Sat Jun 23 21:10:58 2007 +0200

    Make sysctl use a size_t rather than a int. Should fix a 32/64-bit
problem.

commit a0110af4c457d1b2c506b3de5bf497a38b1f09cf
Author: Jesper Louis Andersen <jesper.louis.andersen at gmail.com>
Date:   Sat Jun 23 16:07:11 2007 +0200

    Adding a check to the runtime.

commit 6aeba2ddd5289ea75394560b516f52881aff3ee3
Author: Jesper Louis Andersen <jesper.louis.andersen at gmail.com>
Date:   Sat Jun 23 00:35:04 2007 +0200

    Make the runtime aware of the differences between i386 and amd64
FreeBSD.

commit d63bd90db659f6b58c450c96f9ef075362fba57e
Author: Jesper Louis Andersen <jesper.louis.andersen at gmail.com>
Date:   Sat Jun 23 00:05:02 2007 +0200

    FreeBSD uses the machine specifier of 'amd64' for amd64. Alter
bin/platform

    to understand this.
-------------

ogre% git-diff trunk
---
diff --git a/bin/platform b/bin/platform
index 73ab3c7..5b58e2e 100755
--- a/bin/platform
+++ b/bin/platform
@@ -76,6 +76,9 @@ x86_64*)
 i?86_64)
         HOST_ARCH=amd64
 ;;
+amd64)
+        HOST_ARCH=amd64
+;;
 arm*)
         HOST_ARCH=arm
 ;;
diff --git a/runtime/platform/freebsd.c b/runtime/platform/freebsd.c
index c182532..f4c9927 100644
--- a/runtime/platform/freebsd.c
+++ b/runtime/platform/freebsd.c
@@ -18,7 +18,13 @@ void GC_displayMem () {
 static void catcher (__attribute__ ((unused)) int sig,
                      __attribute__ ((unused)) siginfo_t *sip,
                      ucontext_t *ucp) {
+#if (defined (__x86_64__))
+        GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_rip);
+#elif (defined (__i386__))
         GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_eip);
+#else
+#error Profiling handler is missing for this architecture
+#endif
 }

 void GC_setSigProfHandler (struct sigaction *sa) {
diff --git a/runtime/platform/sysctl.c b/runtime/platform/sysctl.c
index f7381de..2b7ebdf 100644
--- a/runtime/platform/sysctl.c
+++ b/runtime/platform/sysctl.c
@@ -12,7 +12,7 @@ size_t GC_pageSize (void) {
 }

 size_t GC_totalRam (void) {
-  int physMem;
+  size_t physMem;
   size_t len;
   int mib[2];
 ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070623/a3dfe811/attachment.html

More information about the MLton mailing list