I've been trying to get GHC working for x86_64 on Snow Leopard, with a certain amount of success, but have got stuck. Maybe one of you could point me in the right direction. I now have a working compiler, but the linker in the runtime system seems to be missing some stuff. Specifically, in rts/Linker.c, there are references to X86_64_RELOC_UNSIGNED, X86_64_RELOC_SIGNED and so on, but it simply barfs when faced with a X86_64_RELOC_SIGNED_1 etc. I'd thought it would be a matter of adding a few lines of code, but everything I've tried has ended in tears. Trouble is, none of the documentation mentions X86_64_RELOC_SIGNED_1, although it does appear in C headers. It occurs only rarely in source examples, and it really isn't clear to me how I should proceed. Any ideas? Cheers, Barney.
Latest update on getting GHC working 64-bit on Snow Leopard. I've been building 6.8.3, simply because it was the version I had running before so might give fewer problems. To get the compiler working, apply this patch (which I borrowed from the Darcs repository): diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs --- a/compiler/cmm/CLabel.hs +++ b/compiler/cmm/CLabel.hs @@ -816,6 +816,10 @@ pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo -> CLabel -> SDoc #if x86_64_TARGET_ARCH && darwin_TARGET_OS +pprDynamicLinkerAsmLabel CodeStub lbl + = char 'L' <> pprCLabel lbl <> text "$stub" +pprDynamicLinkerAsmLabel SymbolPtr lbl + = char 'L' <> pprCLabel lbl <> text "$non_lazy_ptr" pprDynamicLinkerAsmLabel GotSymbolPtr lbl = pprCLabel lbl <> text "@GOTPCREL" pprDynamicLinkerAsmLabel GotSymbolOffset lbl Make sure you have a working 32-bit GHC as well as libraries (libgmp, etc).for both 32 and 64-bit architectures. Then say ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin make It will compile an x86_64 GHC for you, happily unaware that the GHC you're using for the build is a 32-bit one. The stage1 compiler is, of course, a 32-bit binary that produces 64-bit binaries. I found that the resulting compiler can build itself (stage3) and can say Hello World, so it looks like it works correctly. I've still not got GHCi working, though. I've managed to narrow down the source of the trouble with the linker in GHCi, and it looks like there are some bugs as well as missing parts, which is why it kept launching itself to the moon. Still working on that one: patch to follow. For now, you can at least compile your code and run it non-interactively. Barney.
On 24/09/2009 09:55, Barney Stratford wrote:
Latest update on getting GHC working 64-bit on Snow Leopard. I've been building 6.8.3, simply because it was the version I had running before so might give fewer problems.
To get the compiler working, apply this patch (which I borrowed from the Darcs repository):
diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs --- a/compiler/cmm/CLabel.hs +++ b/compiler/cmm/CLabel.hs @@ -816,6 +816,10 @@ pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo -> CLabel -> SDoc
#if x86_64_TARGET_ARCH && darwin_TARGET_OS +pprDynamicLinkerAsmLabel CodeStub lbl + = char 'L' <> pprCLabel lbl <> text "$stub" +pprDynamicLinkerAsmLabel SymbolPtr lbl + = char 'L' <> pprCLabel lbl <> text "$non_lazy_ptr" pprDynamicLinkerAsmLabel GotSymbolPtr lbl = pprCLabel lbl <> text "@GOTPCREL" pprDynamicLinkerAsmLabel GotSymbolOffset lbl
Make sure you have a working 32-bit GHC as well as libraries (libgmp, etc).for both 32 and 64-bit architectures. Then say
./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-darwin make
It will compile an x86_64 GHC for you, happily unaware that the GHC you're using for the build is a 32-bit one. The stage1 compiler is, of course, a 32-bit binary that produces 64-bit binaries.
I found that the resulting compiler can build itself (stage3) and can say Hello World, so it looks like it works correctly. I've still not got GHCi working, though.
I've managed to narrow down the source of the trouble with the linker in GHCi, and it looks like there are some bugs as well as missing parts, which is why it kept launching itself to the moon. Still working on that one: patch to follow. For now, you can at least compile your code and run it non-interactively.
Nice going - sounds like you've got the furthest so far. Others have been going via an unregisterised build, which seems to be more problematic (though it shouldn't be). It should be possible to use your 6.8.3 to bootstrap your way to 6.12.1, have you tried that? I doubt it will fix your GHCi problems, though. But it should be possible to then make a distribution for others to try. Cheers, Simon
Only limited success with GHCi, I'm afraid. The problem seems to be that Snow Leopard is much stricter about security than Leopard was. (Caveat - I don't really know what I'm talking about.) In particular, I don't think it will let you execute code outside of the __TEXT segment, which is exactly what GHCi tries to do - hence the bus errors. I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it. One change that will be necessary in any case: towards the end of rts/ Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc->r_pcrel); thing += value - baseValue; break; to case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc->r_pcrel); thing += value - baseValue; break; I won't be able to hack on this any more for a few days, as I'm off to the mountains. Maybe someone else can try. Barney.
On 24/09/2009 23:54, Barney Stratford wrote:
Only limited success with GHCi, I'm afraid. The problem seems to be that Snow Leopard is much stricter about security than Leopard was. (Caveat - I don't really know what I'm talking about.) In particular, I don't think it will let you execute code outside of the __TEXT segment, which is exactly what GHCi tries to do - hence the bus errors.
We had similar problems with SELinux, which we worked around by using libffi to allocate our memory; it handles the multiple-mmapping trick that you need to do to avoid having memory that is both writable and executable. You might need to enable this for Darwin too: look in rts/sm/Storage.c:allocateExec(), and change the #ifdef so that the libffi version is used for darwin too.
I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it.
One change that will be necessary in any case: towards the end of rts/Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc->r_pcrel); thing += value - baseValue; break;
to
case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc->r_pcrel); thing += value - baseValue; break;
Manuel, maybe you could validate and push this one? Cheers, Simon
OK, I'm trying to get a more-recent GHC working that has that #ifdef that you mentioned. Specifically, 6.10.4. I've said: ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin --with-gmp-includes='/sw/include' --with- gmp-libraries='/sw/lib' make and it fails, saying it can't find libgmp, even though I've just told it where gmp is. I've copied my mk/build.mk straight from my 6.8.3 build, and it says ReadlineIncludePath=/sw/include SRC_CC_OPTS += -I/sw/include -L/sw/lib SRC_HC_OPTS += -I/sw/include -L/sw/lib EXTRA_HSC2HS_OPTS += -I/sw/include EXTRA_LD_OPTS += -L/sw/lib The resulting error message is: [51 of 51] Compiling Distribution.Simple ( Distribution/Simple.hs, dist-bootstrapping/build/Distribution/Simple.o ) ar: creating archive dist-bootstrapping/build/libHSCabal-1.6.0.3.a cd Cabal && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 install -- distpref=dist-bootstrapping --inplace Installing library in /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/Cabal/dist- bootstrapping/install/usr/local/lib/Cabal-1.6.0.3/ghc-6.8.3 Registering Cabal-1.6.0.3... Reading package info from "dist-bootstrapping/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 clean -- distpref=dist-bootstrapping cleaning... cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 configure -- distpref=dist-bootstrapping --with-compiler=/Users/bjs/Desktop/ GHC_Build/install/bin/ghc --with-hc-pkg=/Users/bjs/Desktop/GHC_Build/ install/bin/ghc-pkg --package-db=/Users/bjs/Desktop/GHC_Build/ ghc-6.10.4/libraries/bootstrapping.conf.tmp Configuring hpc-0.5.0.3... <command-line>: warning: "__PIC__" redefined <built-in>: warning: this is the location of the previous definition cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 build -- distpref=dist-bootstrapping Preprocessing library hpc-0.5.0.3... ld: library not found for -lgmp collect2: ld returned 1 exit status linking dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o failed command was: /usr/bin/gcc -L/Users/bjs/Desktop/GHC_Build/install/lib/ ghc-6.8.3/lib/directory-1.0.0.1 -L/Users/bjs/Desktop/GHC_Build/install/ lib/ghc-6.8.3/lib/filepath-1.1.0.0 -L/Users/bjs/Desktop/GHC_Build/ install/lib/ghc-6.8.3/lib/old-time-1.0.0.0 -L/Users/bjs/Desktop/ GHC_Build/install/lib/ghc-6.8.3/lib/old-locale-1.0.0.0 -L/Users/bjs/ Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/containers-0.1.0.2 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/array-0.1.0.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/base-3.0.2.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3 -lm -lgmp -ldl dist- bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o -o dist-bootstrapping/ build/Trace/Hpc/Reflect_hsc_make make[1]: *** [bootstrapping.conf] Error 1 make: *** [stage1] Error 2 [~/Desktop/GHC_Build/ghc-6.10.4] bjs$ As you can see, it doesn't even attempt to tell gcc where to find libgmp. This has the feeling of an RTM question, and if it is then I apologise. I've not seen anything about this in the M, though. Cheers, Barney.
Am Freitag 25 September 2009 11:56:54 schrieb Barney Stratford:
As you can see, it doesn't even attempt to tell gcc where to find libgmp.
This has the feeling of an RTM question, and if it is then I apologise. I've not seen anything about this in the M, though.
Cheers, Barney.
As a workaround, you might try to set the appropriate enironment variables (check with man gcc which ones are required) to include /sw/include resp. /sw/lib
On 25/09/2009 11:28, Barney Stratford wrote:
As a workaround, you might try to set the appropriate enironment variables Setting LIBRARY_PATH seems to help, but there must be a better way! Thanks.
This is supposed to work, as far as I know: ./configure --with-gmp-libraries=<path> --with-gmp-includes=<path> Cheers, Simon
Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make: /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/ bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc- option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=- L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/ build/installPackage/installPackage-tmp/Main.o ) /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3616:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3677:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3709:0: Bignum number illegal. Absolute 0 assumed. etc... Looking in the assembler file, I get stuff like: Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 37590000000000174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax (That bignum is at line 3616.) Any ideas what might be causing this? Cheers, Barney.
On 08/10/2009 10:57, Barney Stratford wrote:
Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make:
/Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc-option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=-L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/build/installPackage/installPackage-tmp/Main.o )
/var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3616:0:
Bignum number illegal. Absolute 0 assumed.
/var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3677:0:
Bignum number illegal. Absolute 0 assumed.
/var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3709:0:
Bignum number illegal. Absolute 0 assumed.
etc...
Looking in the assembler file, I get stuff like:
Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 37590000000000174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax
(That bignum is at line 3616.) Any ideas what might be causing this?
Almost certainly a misconfiguration somewhere, but it's hard to tell where. Something thinks that words are 32 bits when they are in fact 64, or vice versa. So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? Cheers, Simon
On 08/10/2009 15:07, Barney Stratford wrote:
So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 37590000000000174587920 doesn't even fit into 64 bits, hence the assembler's complaint.
Yes, I see that. GHC keeps these values as Integers internally, so it's possible that some misconfiguration has caused it to produce a values that's out of range, although I agree that the fact that it is bigger than even 2^64 is quite suspicious. I suggest dumping out some intermediate code, e.g. -dppr-cmm -dppr-opt-cmm. If that fails to narrow it down, then you may need to add some debug traces the native code generator to find out where these values are coming from. Cheers, Simon
Simon Marlow:
On 24/09/2009 23:54, Barney Stratford wrote:
I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it.
One change that will be necessary in any case: towards the end of rts/Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc->r_pcrel); thing += value - baseValue; break;
to
case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc->r_pcrel); thing += value - baseValue; break;
Manuel, maybe you could validate and push this one?
I am happy to take care of funnelling Barney's changes into the main repo. However, I think there was at least one more mentioned in another email. Barney, do you have a comprehensive set of the changes that you made (ideally against the HEAD repo, or a nightly snapshot, but if that's difficult, then against 6.10)? And did you try to run the testsuite http://darcs.haskel.org/testsuite with the compiler that you generated? Manuel
participants (4)
-
Barney Stratford -
Daniel Fischer -
Manuel M T Chakravarty -
Simon Marlow