[GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4

[GHC]

#15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4
-------------------------------------+-------------------------------------
        Reporter:  glaubitz          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  m68k
 Type of failure:  Incorrect result  |            Test Case:
  at runtime                         |
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by jrtc27):

 Replying to [comment:5 slyfox]:
 > Replying to [comment:4 slyfox]:
 > > Normally '''COPY''' relocations are used only for immutable
 ('''const''' in C land) data. But '''_closure'''s are mutable. I'll
 double-check generated C code and file a toolchain bug upstream.
 >
 > James (jrtc27) pointed out that '''COPY''' relocations are fine for
 mutable data as long as shared library allows interposition of the symbol.
 James also noted that GHC uses '''-Bsymbolic''' which forbids symbol
 interposition and binds global symbols to library's definition.

 Even for immutable data it can pose problematic if you perform address
 comparisons, but you're right that mutable data can lead to more problems.

 > {{{
 > $ cross=x86_64-pc-linux-gnu- emulator= ./a.sh
 >
 > target: x86_64-pc-linux-gnu-; emulator=; no-pie:
 > main  (before store): things[0] = 99
 > shlib (before store): things[0] = 99
 > main   (after store): things[0] = 45
 > shlib  (after store): things[0] = 99
 > target: x86_64-pc-linux-gnu-; emulator=; pie:
 > main  (before store): things[0] = 99
 > shlib (before store): things[0] = 99
 > main   (after store): things[0] = 45
 > shlib  (after store): things[0] = 99
 > }}}
 >
 > Note: the value of '''things[0]''' disagrees between binary and library
 copy.

 Actually x86_64 is more unusual here in that PIE is *also* broken by this.
 Most architectures will fall back on the normal GOT mechanisms for PIE,
 but on x86_64 RIP-relative addressing is available, giving a cheaper
 position-independent way to access globals (and of course it's still fine
 for PIE because we can still use COPY relocations). If you were to run
 that for i386 or a traditional RISC architecture, you would see that PIE
 did not exhibit the bug.

 Surely the way forward is to ditch `-Bsymbolic`, and ensure that whatever
 non-PIC patterns exist (as mentioned by
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode#LinkingonELF)
 in the DSOs produced are fixed? Presumably the only non-PIC bits are
 whatever would work for PIE (otherwise how on earth can you have a
 variable image base) and must be PC-relative? For code that should be fine
 (you could even use `-Bsymbolic-functions` and I believe it would work),
 and for data there can't be many instances. In fact, I think `-Bsymbolic`
 might well work just fine for NCG as it already tries to avoid COPY
 relocations (does it always successfully avoid them?), in which case we
 could just drop `-Bsymbolic` when compiling via C (GCC should just do the
 right thing if you give it valid C). Thoughts?

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