[GHC] #8935: Obscure linker bug leads to crash in GHCi

[GHC]

#8935: Obscure linker bug leads to crash in GHCi
-------------------------------------+------------------------------------
        Reporter:  simonmar          |            Owner:  simonmar
            Type:  bug               |           Status:  infoneeded
        Priority:  high              |        Milestone:  7.8.3
       Component:  Runtime System    |          Version:  7.8.1-rc2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash        |       Difficulty:  Rocket Science
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by dagit):

 Simon, at the moment I'm just trying to understand this whole thing better
 myself. My uncertainty is in these areas:
   * How the `dlsym()` search should work. For example, I'm not sure if
 `dlsym()` is supposed to look in the `NEEDED` dependencies or not. It
 seems to look in them.
   * Whether glibc implements the above search correctly.
   * Finally, I have no idea what is the right way to fix ghc's linker.

 I assume you're already familiar with the elf linking spec, but here is
 the link just to make sure we're looking at the same doc:
 http://refspecs.linuxbase.org/elf/elf.pdf

 It says:
   * STB_LOCAL Local symbols are not visible outside the object file
 containing their definition. Local symbols of the same name may exist in
 multiple files without interfering with each other.
   * STB_GLOBAL Global symbols are visible to all object files being
 combined. One file's definition of a global symbol will satisfy another
 file's undefined reference to the same global symbol.
   * STB_WEAK Weak symbols resemble global symbols, but their definitions
 have lower precedence.

 I'd say, based on what I see on my machine that `WEAK` seems to be even
 lower priority than `LOCAL`.

 It's interesting that your ld-linux.so doesn't have `environ`, when I grep
 mine I get these hits:
 {{{
 $ readelf -Wa /usr/lib64/ld-linux-x86-64.so.2 | grep environ
    143: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS dl-environ.c
    179: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS environ.c
    268: 00000031e4022168     8 OBJECT  LOCAL  DEFAULT   21 _environ
    275: 00000031e4022168     8 OBJECT  LOCAL  DEFAULT   21 __environ
    300: 00000031e4022168     8 OBJECT  LOCAL  DEFAULT   21 environ
 }}}

 For your libgmp.so does `environ` get defined in any of the deps listed by
 `ldd`?

 The `dlsym` manpage has this (potentially) interesting comment:

 > External  references  in  the  library are resolved using the libraries
 in that library's dependency list and any other libraries previously
 opened with the RTLD_GLOBAL flag.  If the executable was linked with the
 flag "-rdynamic" (or, synonymously, "--export-dynamic"), then the global
 symbols in the executable will also be used to resolve references in a
 dynamically loaded library.

 Please let me know if there is more I can do to help.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler