ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi, I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The binary works well enough to build itself and darcs. There are only sixteen unexpected test suite failures thus far. I am ignoring these for the moment while I get back to thinking about ghci. Note that you need to install libgmp to use the compiler. libgmp from the ports collection works fine. Best Wishes, Greg
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-freebsd.tar.b...
yay! Ian will supply a link from the download page in due course, I'm sure.
No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary.
The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. Cheers, Simon
Hi Simon, On May 30, 2007, at 4:05 PM, Simon Marlow wrote:
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2
yay! Ian will supply a link from the download page in due course, I'm sure.
I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Should I ask for push permission or just send these via the usual darcs send route (now possible, since darcs builds on x86_64)?
The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug:
http://hackage.haskell.org/trac/ghc/ticket/781
the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi.
Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x800000000. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while.
Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time.
FreeBSD/amd64 seems to make a lot of references to static data. When I edited the Linker to ignore out of range relocations and print a message I got dozens while starting GHCi. Best Wishes, Greg
Gregory Wright wrote:
The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug:
http://hackage.haskell.org/trac/ghc/ticket/781
the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi.
Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x800000000. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while.
The linker allocates space for the data in the .data or .bss of the binary. e.g. this is what I get when I refer to environ from a C function: 0000000000500aa8 w O .bss 0000000000000008 environ@@GLIBC_2.2.5 so at runtime, the linker must use this as the location for environ, and links the references from libc to here. In order to do this, the data must have been annotated with a .size directive in the shared library, so the linker knows how much space to allocate for it. In fact it does this for all static data references from the main program; this is the dreaded R_COPY relocation type. I don't really know if its possible to check whether a particular reference is to code or data in GHC's linker - how did you do this? Currently the linker just assumes they're all code, and allocates a jump table in the low 2Gb and re-route jumps through it (see x86_64_high_symbol() in rts/Linker.c). Cheers, Simon
Hi Gregory, On Wed, May 30, 2007 at 05:56:31PM -0400, Gregory Wright wrote:
On May 30, 2007, at 4:05 PM, Simon Marlow wrote:
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2
Great, thanks!
yay! Ian will supply a link from the download page in due course, I'm sure.
Now done.
I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD?
Yup, HEAD is best.
darcs send route (now possible, since darcs builds on x86_64)?
darcs send is fine. Thanks Ian
participants (3)
-
Gregory Wright -
Ian Lynagh -
Simon Marlow