LLVM: Dynamic Library Support
dynamic library status:
* Supported: Linux 64bit, Mac OSX 64bit
* Unsupported: Linux 32bit, Mac OSX 32bit, Windows 32bitThe LLVM backend doesn't support dynamic libraries at the moment.
LLC supports a flag called '-relocation-mode' that can be used to support this, it takes the following options:
default - let the target choose.
static - static code.
pic - PIC code.
dynamic-no-pic - Dynamic references but static codeThis roughly corresponds to GHC -fPIC, and -dynamic flags.
Linux: Simply adding the correct flag to LLC seems to work fine. Mac OSX, Windows: Adding the correct flag doesn't work at all, all programs segfault.
Activity
added LLVM backend Tfeature request Trac import labels
changed milestone to %7.0.2
changed milestone to %7.2.1
It was pointed out to me today that 64 bit OSX has
-fPICturned on by default, because that's what the platform ABI requires (quite sensibly), but GHC disables-fllvmautomatically as a result. Hence you can't use-fllvmon 64-bit OSX at all.I expect we're being too conservative here and it would be fine to enable
-fllvm. As I understand it,-dynamicis the real problem, not-fPIC. David?Trac metadata
Trac field Value Priority normal → high I don't really know without testing. What is the state of the 64bit version of GHC on OSX? Ben Lippmeier has graciously provided me with access to his OS X machine and I've been using this to do any testing and development. His machine seems to be running a 32bit kernel though (although its running 10.6 on Core i7 hardware). It seems though that I should be able to run a 64bit version of GHC on this still, correct? Also how closely does GHC follow the standard ABI for PIC on OSX? I think you're correct that -dynamic is the real problem though.
Replying to [ticket:4210#comment:50139 dterei]:
I don't really know without testing. What is the state of the 64bit version of GHC on OSX? Ben Lippmeier has graciously provided me with access to his OS X machine and I've been using this to do any testing and development. His machine seems to be running a 32bit kernel though (although its running 10.6 on Core i7 hardware). It seems though that I should be able to run a 64bit version of GHC on this still, correct?
I'm running a 64-bit GHC with a 32-bit kernel and it works fine:
$ uname -a Darwin tibell-macbookpro.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i386 $ sysctl hw | grep 64bit hw.cpu64bit_capable: 1 $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","7.0.3") ,("Booter version","7.0.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","YES") ,("Have llvm code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p ") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3") ,("Global Package DB","/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/package.conf.d") ,("C compiler flags","[\"-m64\",\"-fno-stack-protector\"]") ,("Gcc Linker flags","[\"-m64\"]") ,("Ld Linker flags","[\"-arch\",\"x86_64\"]") ]So I had a test of it on OSX. It mostly works but there are a significant amount of testsuite failures. On 32bit OSX there are no failure with the LLVM backend. On 64bit using -fPIC there are around 70 failures. I haven't looked into why they are failing at all yet, most the ffi tests seem to fail so potentially all the failures are related to that. Not sure when I'll have time to figure out what the failures are caused by so I'm tempted to enable the LLVM backend under 64bit OSX and just add a big warning that it has a good chance of not working... Depends on when 7.2 release happens I guess.
Test summary:
OVERALL SUMMARY for test run started at Thu Apr 28 13:08:36 EST 2011 2726 total tests, which gave rise to 11658 test cases, of which 0 caused framework failures 2103 were skipped 9174 expected passes 278 expected failures 0 unexpected passes 103 unexpected failures Unexpected failures: 1185(optllvm) 1288(optllvm) 1679(optllvm) 2276(optllvm) 2469(optllvm) 2594(optllvm) 4038(optllvm) 4221(optllvm) CPUTime001(normal,ghci,threaded1,threaded2,profthreaded) T1969(normal) T3245(normal,hpc,optasm,profasm,threaded1,threaded2,profthreaded,optllvm) T3822(hpc,ghci) T4144(optllvm) T4801(normal) ThreadDelay001(ghci) annrun01(normal,hpc,optasm,ghci,threaded1,threaded2,optllvm) arith001(optllvm) arith008(optllvm) arrowrun004(optllvm) barton-mangler-bug(optllvm) cgrun015(optllvm) cgrun034(optllvm) cgrun044(optllvm) conc021(optllvm) conc036(optllvm) conc039(optllvm) conc040(optllvm) derefnull(profthreaded) divbyzero(profthreaded) dph-diophantine-opt(normal,threaded1,threaded2) dynamic001(normal,hpc,optasm,profasm,ghci,threaded1,threaded2,profthreaded,optllvm) expfloat(optllvm) fed001(optllvm) ffi003(optllvm) ffi005(optllvm) ffi006(optllvm) ffi007(optllvm) ffi008(optllvm) ffi009(optllvm) ffi010(optllvm) ffi011(optllvm) ffi013(optllvm) ffi016(optllvm) ffi019(optllvm) ffi020(optllvm) ffi021(optllvm) fptr02(normal,hpc,optasm,threaded1,threaded2) fun_insts(optllvm) hpc_markup_multi_001(normal) hpc_markup_multi_002(normal) hpc_markup_multi_003(normal) joao-circular(optllvm) jules_xref(optllvm) num009(optllvm) num010(optllvm) objc-hi(profasm,ghci,profthreaded) outofmem(normal) signals002(ghci,optllvm) signals004(ghci,threaded1,threaded2,profthreaded) spec001(normal,hpc,optasm,profasm) time002(ghci) time004(ghci)mentioned in commit 22423fc9
OK Fixed up 64bit OSX. Commit 22423fc9.
Simon M, perhaps change the priority of this back to Normal or even low now.
Oh sorry, you also need to pull in commit 50e0db45 which updates the mangler to work on 64bit OSX.
David: in commit 22423fc9 you disabled
-fllvmon OS X 64 unconditionally, because it has-fPICon by default. Was that intentional? This was the problem that originally caused us to raise this ticket to high prio, and it seems to be back again. I'm confused.
