GHCi on x86_64, cannot link to static data in shared libs

[guest]

System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp with a segfault. (x86_64)

[aleator@thoth HopenCV]$ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv "USER"
Loading package unix-1.0 ... linking ... done.
Just "aleator"
Prelude System.Posix.Env> getEnvironment
Segmentation fault

[simonmar]

I've fixed part of the problem (getEnvironment was broken), but this still won't work with GHCi on x86_64 due to another problem: for annoying reasons the dynamic linker doesn't support linking to static data in shared libraries, which the 'environ' variable in C is. So I'm leaving the bug open with a revised heading.

[simonmar]

If we get shared libraries working, this one will be fixed.

[simonmar]

We've committed Wolfgang's patch to Linker.c that understands the PIC relocations on x86_64. This means that it is possible to compile the Haskell code using -fPIC to workaround this problem. Shared libraries will also make this less of an issue, as it will then only be a problem for modules rather than packages that are loaded into GHCi.

[simonmar]

Let's look into this for 6.14.1.

[simonmar]

Ok, to elaborate on this. The solution would be to compile everything with -fPIC on x86-64, ie. enable -fPIC by default. We have to measure the performance impact of doing that, which might not be a problem.

[igloo]

The session in the description now works, and getEnvironment01 passes all ways, on amd64/Linux.

[simonmar]

Replying to igloo:

The session in the description now works, and getEnvironment01 passes all ways, on amd64/Linux.

This bug definitely still exists. Perhaps this particular test case doesn't trigger it any more?

[igloo]

Simon, do you have a testcase for this?

[simonmar]

Replying to igloo:

Simon, do you have a testcase for this?

~/scratch/781 > cat a.c
int a = 42;
~/scratch/781 > gcc -shared a.c -o a.so
~/scratch/781 > cat b.hs
{-# LANGUAGE Haskell2010 #-}

import Foreign
import Foreign.C

foreign import ccall "&a" pa :: Ptr CInt

main = peek pa >>= print
~/scratch/781 > ghc -c b.hs
compilation IS NOT required
~/scratch/781 > ghc --interactive b.hs `pwd`/a.so
GHCi, version 6.13.20100826: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) /home/simonmar/scratch/781/a.so ... done
final link ... done
Ok, modules loaded: Main.
Prelude Main> main
-907777
Prelude Main> 

[simonmar]

To fix this we need to use -fPIC by default on x86_64, which is also what we need for #3658. So let's plan to do this in 7.2, when we've thought through the implications of moving to dynamic linking by default.

[simonmar]

punting; we're not moving to dynamic linking by default for 7.4.1.

[simonmar]

Moving this to the same milestone as #3658, the ticket it depends on.

One question I have: is this also an issue on Windows?

[igloo]

Looks like it only affects Linux:

amd64/Linux:

Prelude Main> main
-907777

amd64/OSX:

Prelude Main> main
42

amd64/Windows:

Prelude Main> main
42