[Dotgnu-libjit] Mac OS X compatibility patchset

[Arto Bendiken]

I had some trouble getting libjit built on Mac OS X; after banging my
head against the wall for a while, I have managed to cook up this
patchset against CVS HEAD:

  
http://github.com/bendiken/portfiles/commit/61be2a3303e0d4fa351038ab558ecf2b9710691d

This contains patches for jit/jit-apply-x86.h, tools/gen-apply.c, and
tools/gen-apply-macosx.h, and addresses the following issues.

== Problem #1: missing floating point JIT_APPLY_* constants ==

  
http://github.com/bendiken/portfiles/tree/master/devel/libjit/files/patch-tools-gen-apply-macosx.h.diff

    (when compiling tools/gen-apply.o)
    gen-apply.c:135: error: 'JIT_APPLY_NUM_DOUBLE_REGS' undeclared
here (not in a function)
    gen-apply.c:136: error: 'JIT_APPLY_NUM_NFLOAT_REGS' undeclared
here (not in a function)
    gen-apply.c:150: error: 'JIT_APPLY_DOUBLES_IN_WORD_REGS'
undeclared here (not in a function)
    gen-apply.c:151: error: 'JIT_APPLY_NFLOATS_IN_WORD_REGS'
undeclared here (not in a function)
    gen-apply.c:153: error: 'JIT_APPLY_RETURN_DOUBLES_AFTER'
undeclared here (not in a function)
    gen-apply.c:154: error: 'JIT_APPLY_RETURN_NFLOATS_AFTER'
undeclared here (not in a function)

  These #defines seem to have been introduced in tools/gen-apply.c not
that long ago, but they are still missing from the non-autodetected
configuration in tools/gen-apply-macosx.h. I had no idea what to
define them as, so I simply set them all to zeroes. Probably not the
best solution, but it allowed compilation to continue until the next
roadblock...

== Problem #2: invalid external reference to memcpy() ==

  
http://github.com/bendiken/portfiles/tree/master/devel/libjit/files/patch-jit-jit-apply-x86.h.diff

    (when linking tools/gen-apply)
    /usr/bin/ld: Undefined symbols: memcpy
    collect2: ld returned 1 exit status
    make[2]: *** [gen-apply] Error 1

  I ran into this problem with all libjit versions that I tried to
compile: 0.0.6, 0.1.0, 0.1.1-20071113, and the latest CVS. I tracked
it down to line 57 in jit/jit-apply-x86.h, in the midst of the
jit_builtin_apply() macro's inline assembly:

    #define jit_builtin_apply(func,args,size,return_float,return_buf)       \
    ...
                                "call memcpy\n\t" \

  This fails on Mac OS X because references to external symbols are
late-bound through a PIC stub that gets resolved when first used.
Instead of "memcpy", one needs to invoke "L_memcpy$stub". Here's a
great overview of the whole sordid mess from the point of view of
compiler construction:

    http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode

  The jit/jit-apply-x86-64.h file probably will need similar Mac OS
X-specific fixes. I don't just now have access to a 64-bit system to
check that out, but I think the currently-used "@PLT" symbol suffix
only works on Linux.

== Problem #3: invalid static reference to mem_copy() ==

  
http://github.com/bendiken/portfiles/tree/master/devel/libjit/files/patch-tools-gen-apply.c.diff

    (when linking the final libjit.dylib library)
    ld: Undefined symbols: _mem_copy
    /usr/bin/libtool: internal link edit command failed
    make[2]: *** [libjit.la] Error 1

  Given that JIT_MEMCPY is defined in tools/gen-apply.c to be
"mem_copy" when compiling tools/gen-apply, this will break when
linking on Mac OS X. The problem this time is that Darwin's GNU
toolchain prefixes all C symbols with an underscore, so the procedure
"mem_copy" should actually be called as "_mem_copy" from
jit_builtin_apply().

  On 32-bit OS X, problem #2 would have masked this issue because the
"memcpy" call was hardcoded in jit/jit-apply-x86.h anyway. On 64-bit
Macs, it would've failed as jit/jit-apply-x86-64.h does actually honor
the value of JIT_MEMCPY when previously defined.

== Results ==

The aforementioned three patches apply cleanly to the 0.1.1-20071113
snapshot as well as to CVS HEAD, and made libjit compile for me on Mac
OS X 10.4.11 running on a 32-bit x86 CPU. The last two patches also
apply against 0.1.0, and adding in tools/gen-apply-macosx.h from CVS
makes 0.1.0 compile fine on the Mac.

I'm not yet sure whether libjit actually *works* on Mac OS X, however.
My intention is to play with Paul Brannan's ruby-libjit bindings, and
while the bindings compile fine, all ruby-libjit unit tests are
failing me so far, the methods returning garbage (e.g. "-1073751328"
instead of "42"). Not sure yet if that's a problem in the Ruby
bindings themselves, libjit on Mac OS X generally, or the versions
used (I tried libjit 0.1.0 as well as last year's snapshot).

I'll continue onwards to debugging ruby-libjit, but I suspect libjit
may have further Mac issues to overcome. It seems a redundant
observation that libjit probably hasn't had many (any?) Mac OS X
users, given these problems, but gotta start somewhere :-)

Best regards from sunny Spain,
Arto

-- 
Arto Bendiken | http://bendiken.net/