Wolfgang Thaller wrote:
On 17-Sep-07, at 7:20 PM, Sven Panne wrote:
Now we get a R_X86_64_GOTPCREL and things work as expected. Alas, our GHC
Linker can't handle such a relocation,
That shouldn't be a lot of work. The same relocation is already
implemented for Darwin/x86_64.
[...] and somehow this has to work even in
the non-PIC case. What we currently do in x86_64_high_symbol for the
R_X86_64_32 relocation is completely wrong for data references, and
this is
even mentioned in the comment.
Yes, we even have a ticket for it:
http://hackage.haskell.org/trac/ghc/ticket/781
I think that it is next to impossible to implement this correctly. If a
symbol is copied into the executable's data section, the references from
shared libraries to the symbol have to be updated to point to the new
symbol as well. When loading a dynamic library, the system dynamic
linker decides whether it needs to do this; unless we ship GHCi with a
modified version of ld.so, it will do so only for symbols where a COPY
relocation is present.
My recommendation would be implement the PIC relocations in the
ELF/X86_64 linker and then to require -fPIC for GHCi libs on that platform.
Right, but for packages we can compile them as shared libraries and use the
system linker, so the GHCi linker isn't involved. So when we have shared
library support on all major platforms (perhaps 6.8.2) this problem will at
least partly go away. It'll still be an issue for loading .o files in
GHCi, and if this is important then we should do as you suggest and require
-fPIC.
Sven: one workaround for now is to access your data by calling a C wrapper
function in a shared library. This is how we manage to access errno, for
example.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
