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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to