Bug#1089921: ghc: Cherry-pick upstream patch to fix "relocation R_LARCH_B26 overflow"

[王鑫]

Package: ghc
Version: 9.6.6-3
Severity: important
Tags: ftbfs help
User: debian-loongarch at lists.debian.org
Usertags: loong64

Hi maintainers，

We have cherry-picked 5 commits from upstream for the B26 overflow issue.
The local validation result is: haskell-pandoc build passes by building ghc-->haskell-*-->haskell-pandoc.

We intend to remove the previous patch backported by fanpeng as follows.
```
ghc (9.6.6-3) unstable; urgency=medium


   [ fanpeng <fanpeng at loongson.cn> ]
   * debian/patches/7e2d3eb507da184cf3337d36715fd82a81643d91.patch:
     - upstream fix for loong64 build failures (Closes: #1085966)
```

The attached new patches fix the "B26 overflow" problem by simply adding the -mcmodel=medium moduleflag to LLVM IR.  
Adding the moduleflag to the generated LLVM IR is already implemented in the ghc upstream, but not in ghc-9.6.6. So we need to backport these patches to ghc-9.6.6 in order to pass the -mcmodel=medium moduleflag to the LLVM 
IR. In addition, for the behavior “pass -mcmodel=medium moduleflag to LoongArch's LLVM 
IR”, we have implemented the code, and we have pushed the patch to ghc upstream already, so what we are doing this time is just backporting.

A few of our guidelines for submitting these patches are as follows, in order of priority.
1. Don't modify public Functionality, such as Functionality of other architectures except LoongArch.
2. Backporting code directly from upstream to ghc-9.6.6, try not to modify patches.
3. Backport and modify as little as possible.

The attachment includes 5 patches as follows
The number at the top of the patch name indicates the order in which the patches should be applied.

Both 1) and 2) are directly backported from upstream. 3) is the changed upstream patch, in fact the content is the same as the upstream patch, but due to the inconsistency between ghc-9.6.6 and ghc upstream's baseline, i.e., the line number of the upstream patch does not match the code in ghc-9.6.6, so we have to manually apply the content of upstream patch. 4) The modified upstream patch (the one we committed to upstream) has the same problem as 3), the line number of the upstream patch does not match the code in ghc-9.6.6, so we have to apply the content of upstream patch manually. And some minor modifications were made. 1)-4) are backported from upstream. Their corresponding upstream commitIDs are stored in the corresponding patch files. 5) is for the debian/rules change

The details of the attached patches are as follows:
- patch: 0001-llvmGen-Add-export-list-to-GHC.Llvm.MetaData.patch
Cherry-pick from upstream
The corresponding upstream commit is: fcfc1777c22ad47613256c3c5e7304cfd29bc761
Role:  required to add a moduleflag to the llvm IR.

- patch: 0002-llvmGen-Allow-LlvmLits-in-MetaExprs.patch
Cherry-pick from upstream
The corresponding upstream commit is: 5880fff6d353a14785c457999fded5a7100c9514
Role: required to add a moduleflag to the llvm IR.

- patch: 0003-llvmGen-Introduce-infrastructure-for-module-flag-metadata.patch
Cherry-pick from upstream
The corresponding upstream commit is: a6a3874276ced1b037365c059dcd0a758e813a5b
Role: required to add a moduleflag to the llvm IR.

- patch: 0004-llvmGen-Introduce-infrastructure-for-module-flag-metadata.patch
Cherry-pick from upstream with little change.
The corresponding upstream commit is: a6a3874276ced1b037365c059dcd0a758e813a5b
Role: required to add a moduleflag to the llvm IR.
NOTE: We made a little change on the upstream patch because we have to: without the change, a large number of patches would need to be backported to ghc-9.6.6 so that the upstream patch(a6a3874276ced1b037365c059dcd0a758e813a5b) could be backported to ghc-9.6.6, and one of these would break the public interface, i.e., the stack alignment ghc option would be removed. We don't want that happen, so we have to made the change on the upstream patch. 

- patch: 0005-rules-pass-mcmodel-medium-option-to-C-files-on-LoongArch
Not cherry-pick from upstream
Role: 1) C files in rts are compiled using the C compiler, and 2) when compiling some software, the object files generated by some C code are linked together with the program's object files. This patch passes the -mcmodel=medium option to the C compiler.


Best regards,
Xin Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-llvmGen-Add-export-list-to-GHC.Llvm.MetaData.patch
Type: application/octet-stream
Size: 747 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-llvmGen-Allow-LlvmLits-in-MetaExprs.patch
Type: application/octet-stream
Size: 1396 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-llvmGen-Introduce-infrastructure-for-module-flag-metadata.patch
Type: application/octet-stream
Size: 2500 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-llvmGen-Pass-mcmodel-medium-option-to-LLVM-backend-on-LoongArch.patch
Type: application/octet-stream
Size: 3243 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-rules-pass-mcmodel-medium-option-to-C-files-on-LoongArch.patch
Type: application/octet-stream
Size: 713 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20241214/dfcf73fd/attachment-0004.obj>