On 01/06/2009 23:39, Sven Panne wrote:
So my question is again: Why is -fPIC not the default for GHC on x86_64? If we
don't want the overhead, that's OK (any benchmark numbers?), but then GHC's
documentation should really contain a big, fat warning that GHCi's dynamic
linker gets cases like the one above wrong.
There is a ticket, BTW:
http://hackage.haskell.org/trac/ghc/ticket/781
I've milestoned it for 6.12.1 and made it high priority.
I think the only reason that -fPIC is not the default right now on
x86_64 is that (a) it's (still) experimental, and (b) we don't know what
performance implications it has. Duncan will hopefully be able to
resolve both in due course.
Duncan: just to clarify, the problem here is that in the x86_64 small
memory model (the default), external references from non-PIC code are
assigned 32-bit addresses. ld.so makes this work in two ways:
* if the symbol points to code, then a jump trampoline is installed
in the PLT, and the 32-bit address points to it
* if the symbol points to data, then the data object is moved with
the dreaded R_COPY relocation, so that it ends up within the
low 2Gb and the 32-bit relocation is large enough.
the problem is that in GHCi's linker we don't know which symbols point
to data and which point to code. So we assume they point to code (data
is quite rare), and install trampolines. If we use -fPIC, then external
references are made via the PLT or GOT, and the problem doesn't occur.
I mentioned this in a comment on #1876:
http://hackage.haskell.org/trac/ghc/ticket/1876#comment:11
One thing we could do to help would be to spot
foreign import ccall "&foo" foo :: Ptr T
where T is not a function type, and emit a warning suggesting the use of
-fPIC.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
