[Git][haskell-team/DHG_packages][master] ghc: apply patch to disable -Bsymbolic on unregisterised architectures. closes: #904055.

[Clint Adams]

Clint Adams pushed to branch master at Debian Haskell Group / DHG_packages


Commits:
40251373 by Clint Adams at 2018-07-18T18:58:43-04:00
ghc: apply patch to disable -Bsymbolic on unregisterised architectures.  closes: #904055.

- - - - -


3 changed files:

- p/ghc/debian/changelog
- + p/ghc/debian/patches/bsymbolic-only-for-registerised.patch
- p/ghc/debian/patches/series


Changes:

=====================================
p/ghc/debian/changelog
=====================================
--- a/p/ghc/debian/changelog
+++ b/p/ghc/debian/changelog
@@ -1,3 +1,10 @@
+ghc (8.2.2-5) UNRELEASED; urgency=medium
+
+  * Apply patch to disable -Bsymbolic on unregisterised
+    architectures.  closes: #904055.
+
+ -- Clint Adams <clint at debian.org>  Wed, 18 Jul 2018 18:56:46 -0400
+
 ghc (8.2.2-4) unstable; urgency=medium
 
   [ Clint Adams ]


=====================================
p/ghc/debian/patches/bsymbolic-only-for-registerised.patch
=====================================
--- /dev/null
+++ b/p/ghc/debian/patches/bsymbolic-only-for-registerised.patch
@@ -0,0 +1,71 @@
+Description: driver: skip -Bsymbolic on unregisterised targets
+ Trac #15338 is yet another example where -Bsymbolic breaks
+ semantics of a C program: global variable duplication happens
+ and unsafePerformIO creates two stdout copies.
+ .
+ When -Bsymbolic is not used both C compiler and linker agree
+ on how global variables are handled. In case of sh4 it consists
+ on a few assertions:
+ .
+ 1. global variable is exported from shared library
+ 2. code is referred to this variable via GOT-like mechanism to allow
+    interposition
+ 3. global variable is present .bss section on an executable
+    (as an R_*_COPY relocation: symbol contents is copied at executable
+    startup time)
+ 4. and symbol in executable interposes symbol in shared library.
+ .
+ This way both code in shared library and code in executable refer
+ to a copy of global variable in .bss section of an executable.
+ .
+ Unfortunately -Bsymbolic option breaks assumption [2.] and generates
+ direct references to the symbol. This causes mismatch between
+ values seen from executable and values seen from shared library code.
+ .
+ This change disables '-Bsymbolic' for unregisterised targets.
+
+--- a/compiler/main/SysTools.hs
++++ b/compiler/main/SysTools.hs
+@@ -1741,9 +1741,12 @@
+             -------------------------------------------------------------------
+ 
+             let output_fn = case o_file of { Just s -> s; Nothing -> "a.out"; }
++                unregisterised = platformUnregisterised (targetPlatform dflags)
+             let bsymbolicFlag = -- we need symbolic linking to resolve
+-                                -- non-PIC intra-package-relocations
+-                                ["-Wl,-Bsymbolic"]
++                                -- non-PIC intra-package-relocations for
++                                -- performance (where symbolic linking works)
++                                -- See Note [-Bsymbolic assumptions by GHC]
++                                ["-Wl,-Bsymbolic" | not unregisterised]
+ 
+             runLink dflags (
+                     map Option verbFlags
+@@ -1800,3 +1803,27 @@
+     -- reverse because they're added in reverse order from the cmd line:
+     framework_opts = concat [ ["-framework", fw]
+                             | fw <- reverse frameworks ]
++
++{-
++Note [-Bsymbolic assumptions by GHC]
++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++
++GHC has a few assumptions about interaction of relocations in NCG and linker:
++
++1. -Bsymbolic resolves internal references when the shared library is linked,
++   which is important for performance.
++2. When there is a reference to data in a shared library from the main program,
++   the runtime linker relocates the data object into the main program using an
++   R_*_COPY relocation.
++3. If we used -Bsymbolic, then this results in multiple copies of the data
++   object, because some references have already been resolved to point to the
++   original instance. This is bad!
++
++We work around [3.] for native compiled code by avoiding the generation of
++R_*_COPY relocations.
++
++Unregisterised compiler can't evade R_*_COPY relocations easily thus we disable
++-Bsymbolic linking there.
++
++See related Trac tickets: #4210, #15338
++-}


=====================================
p/ghc/debian/patches/series
=====================================
--- a/p/ghc/debian/patches/series
+++ b/p/ghc/debian/patches/series
@@ -10,3 +10,4 @@ use-stage1-binaries-for-install.patch
 build-unlit-and-hp2ps-twice.patch
 fix-hssplicety.patch
 lower-optimization-for-unreg.patch
+bsymbolic-only-for-registerised.patch



View it on GitLab: https://salsa.debian.org/haskell-team/DHG_packages/commit/40251373c5435bb14835ae731d2991c38205fe8a

-- 
View it on GitLab: https://salsa.debian.org/haskell-team/DHG_packages/commit/40251373c5435bb14835ae731d2991c38205fe8a
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-commits/attachments/20180718/3ff00d8c/attachment-0001.html>