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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
