Re: [HOpenGL] renderString not working in ghci

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