ghc-6.6.1 for FreeBSD/amd64 binary distribution

Simon Marlow simonmarhaskell at
Fri Jun 1 04:39:45 EDT 2007

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:
>> 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).


More information about the Glasgow-haskell-users mailing list