<br><br><div><span class="gmail_quote">On 6/23/07, <b class="gmail_sendername">Matthew Fluet</b> <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jesper Louis Andersen wrote:<br>> The runtime only required a single change to be ported.<br><br>Great!</blockquote><div><br>Indeed! I have run into a runtime problem in the mean time, but I'll explain<br>that later. I wont be able to look at fully until after the 28th but if anybody
<br>has suggestions to do something about this, I'll gladly hear about it.<br><br>I am not yet sure if we are denied the allocation size we try to map. I will check that<br>when I get some time. I have a hunch this might be the case as FreeBSD generally
<br>has limits on such things.<br> <br></div>I opted for bootstrapping 2a). Only thing i needed to change was <br>"target map" --> "targetmap" and to copy mllex/mlyacc over as<br>well. I also needed a 32bit version of libGMP, but that was expected.
<br><br>I use the following crude shell script<br>---<br>#!/bin/sh <br>
<br>#gmake clean <br>gmake dirs runtime <br>cp build.bak/lib/mlton-compile build/lib
<br>cp build.bak/bin/mllex build/bin <br>cp build.bak/bin/mlyacc build/bin <br>gmake world-no-check script mlbpathmap targetmap constants libraries tools
<br>gmake compiler <br>gmake world <br>---<br><br>Current diff follows. I maintain an off-tree in git (Linus Torvalds SCM system) which is tied to MLton SVN
<br>through a conduit program, git-svn. The advantage is that branches are actually easy to work with in<br>git, compared to SVN. However, I found the learning curve to be quite steep.<br><br>Some notes:<br>* Teach bin/platform to understand amd64 as a HOST_ARCH on FreeBSD
<br><br>* Teach the ''catcher'' that we are a 64-bit arch by adopting the same scheme as in the linux port<br><br>* It is wrong for the sysctl to return an int now. We get an ENOMEM from sysctl since the<br>
physmem doesn't necessarily fit in a 32-bit value. I hope size_t is enough and correct and works<br>on x86 as well.<br><br>However, this is not enough! Our runtime enters an infinite loop on the heap-allocation for any
<br>program. I instrumented mllex with a debug runtime and added some printfs since I couldn't figure<br>out the maze in the C code for adding DEBUG of the GC.<br><br>We are looping with:<br><br>ogre% ./build/bin/mllex | head -n 60
<br>physMem: 1061425152<br>Couldn't map 0, 94208<br>Couldn't map f8000000, 94208<br>Couldn't map f0000000, 94208<br>Couldn't map e8000000, 94208<br>Couldn't map e0000000, 94208<br>Couldn't map d8000000, 94208
<br>Couldn't map d0000000, 94208<br>Couldn't map c8000000, 94208<br>Couldn't map c0000000, 94208<br>Couldn't map b8000000, 94208<br>Couldn't map b0000000, 94208<br>Couldn't map a8000000, 94208<br>Couldn't map a0000000, 94208
<br>Couldn't map 98000000, 94208<br>Couldn't map 90000000, 94208<br>Couldn't map 88000000, 94208<br>Couldn't map 80000000, 94208<br>Couldn't map 78000000, 94208<br>Couldn't map 70000000, 94208<br>Couldn't map 68000000, 94208
<br>Couldn't map 60000000, 94208<br>Couldn't map 58000000, 94208<br>Couldn't map 50000000, 94208<br>Couldn't map 48000000, 94208<br>Couldn't map 40000000, 94208<br>Couldn't map 38000000, 94208<br>Couldn't map 30000000, 94208
<br>Couldn't map 28000000, 94208<br>Couldn't map 20000000, 94208<br>Couldn't map 18000000, 94208<br>Couldn't map 10000000, 94208<br>Couldn't map 8000000, 94208<br>Couldn't map 0, 94208<br>Couldn't map f8000000, 94208
<br>Couldn't map f0000000, 94208<br>Couldn't map e8000000, 94208<br>...<br><br>Where I instrumented a print of the address and size of the failing mmap() call inside<br>the code. GDB:<br><br>Breakpoint 1, 0x000000003813e5c0 in mmap () from /lib/libc.so.6
<br>(gdb) bt<br>#0 0x000000003813e5c0 in mmap () from /lib/libc.so.6<br>#1 0x000000000044bb4f in mmapAnon (start=0xf7fffffff8000000, <br> length=94208) at platform/mmap.c:2<br>#2 0x000000000044bb29 in GC_mmapAnon (<br>
start=0xf7fffffff8000000, length=94208)<br> at platform/use-mmap.c:12<br>#3 0x00000000004453d4 in createHeap (s=0x2c68, h=0x567308, <br> desiredSize=17870283321271910400, minSize=5658496)<br> at gc/heap.c:184
<br>#4 0x0000000000446039 in initWorld (s=0x566f20)<br> at gc/init-world.c:144<br>#5 0x0000000000446e56 in GC_init (s=0x566f20, argc=1, argv=0x1)<br> at gc/init.c:334<br>#6 0x000000000044b3fe in MLton_init (argc=1,
<br> argv=0x7fffffffe598, s=0xf7fffffff8000000) at platform.c:20<br>#7 0x0000000000402ed8 in main (argc=-134217728, argv=0x17000)<br> at /tmp/file0NuI7N.3.c:1562<br>(gdb) down<br>#3 0x00000000004453d4 in createHeap (s=0x2c68, h=0x567308,
<br> desiredSize=17870283321271910400, minSize=5658496)<br> at gc/heap.c:184<br>184 h->start = GC_mmapAnon ((pointer)address, h->size);<br>(gdb) print address<br>$1 = 17870283321271910400<br>(gdb) print h->size
<br>$2 = 94208<br><br>ogre% git-branch<br> freebsd-fix-runtime-bugs<br>* freebsd-port-branch<br> master<br> mlton-2005<br> mlton-trunk<br> port-amd64-freebsd<br> ssa-tree-cleanup<br><br>git-log -20 output:<br>commit 467cdf0a4b20f6913838aa7e0e78da949f03c09b
<br>Author: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>><br>Date: Sat Jun 23 21:15:22 2007 +0200<br><br> Get rid of #include <assert.h> again.
<br><br>commit f3ba5ec5d8d65a319ed419d79b837c054e35d281<br>Author: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>><br>Date: Sat Jun 23 21:10:58 2007 +0200
<br><br> Make sysctl use a size_t rather than a int. Should fix a 32/64-bit problem.<br><br>commit a0110af4c457d1b2c506b3de5bf497a38b1f09cf<br>Author: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">
jesper.louis.andersen@gmail.com</a>><br>Date: Sat Jun 23 16:07:11 2007 +0200<br><br> Adding a check to the runtime.<br><br>commit 6aeba2ddd5289ea75394560b516f52881aff3ee3<br>Author: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">
jesper.louis.andersen@gmail.com</a>><br>Date: Sat Jun 23 00:35:04 2007 +0200<br><br> Make the runtime aware of the differences between i386 and amd64 FreeBSD.<br><br>commit d63bd90db659f6b58c450c96f9ef075362fba57e
<br>Author: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>><br>Date: Sat Jun 23 00:05:02 2007 +0200<br><br> FreeBSD uses the machine specifier of 'amd64' for amd64. Alter bin/platform
<br> <br> to understand this.<br>-------------<br><br>ogre% git-diff trunk<br>---<br>diff --git a/bin/platform b/bin/platform<br>index 73ab3c7..5b58e2e 100755<br>--- a/bin/platform<br>+++ b/bin/platform<br>@@ -76,6 +76,9 @@ x86_64*)
<br> i?86_64)<br> HOST_ARCH=amd64<br> ;;<br>+amd64)<br>+ HOST_ARCH=amd64<br>+;;<br> arm*)<br> HOST_ARCH=arm<br> ;;<br>diff --git a/runtime/platform/freebsd.c b/runtime/platform/freebsd.c<br>index c182532..f4c9927 100644
<br>--- a/runtime/platform/freebsd.c<br>+++ b/runtime/platform/freebsd.c<br>@@ -18,7 +18,13 @@ void GC_displayMem () {<br> static void catcher (__attribute__ ((unused)) int sig,<br> __attribute__ ((unused)) siginfo_t *sip,
<br> ucontext_t *ucp) {<br>+#if (defined (__x86_64__))<br>+ GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_rip);<br>+#elif (defined (__i386__))<br> GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_eip);
<br>+#else<br>+#error Profiling handler is missing for this architecture<br>+#endif<br> }<br> <br> void GC_setSigProfHandler (struct sigaction *sa) {<br>diff --git a/runtime/platform/sysctl.c b/runtime/platform/sysctl.c<br>
index f7381de..2b7ebdf 100644<br>--- a/runtime/platform/sysctl.c<br>+++ b/runtime/platform/sysctl.c<br>@@ -12,7 +12,7 @@ size_t GC_pageSize (void) {<br> }<br> <br> size_t GC_totalRam (void) {<br>- int physMem;<br>+ size_t physMem;
<br> size_t len;<br> int mib[2];<br> ----<br></div>