From e82afa18945b714bb4c579c0328ee869f516100b Mon Sep 17 00:00:00 2001
From: sternenseemann <sternenseemann@systemli.org>
Date: Fri, 23 May 2025 10:52:11 +0200
Subject: [PATCH] haskell.compiler.ghc94: don't roundtrip C compilation via
 assembly

GHC can be used to compile C sources which causes it to drive the
configured C compiler. This is particularly relevant during GHC's own
compilation, e.g. when building the rts. GHC takes a peculiar approach,
always generating intermediate assembly instead of letting the C
compiler emit object files directly. This causes an assembler check in
clang >= 18 to fail on rts/StgCRun.c, failing the GHC build on darwin
completely.

Later GHC versions don't exhibit this issue since object code is emitted
directly since 9.6. The easiest way to resolve the compilation failure
seems to backport this change. However, the patch only applies on
GHC 9.4 which is done here. The patch may be difficult to backport
further, as the changed code was extensively refactored in GHC 9.4.

Reference #367686.

(cherry picked from commit 16dca700d737702eb122fd50f5794ecb8a75e491)
---
 .../ghc/common-make-native-bignum.nix         | 39 ++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/pkgs/development/compilers/ghc/common-make-native-bignum.nix b/pkgs/development/compilers/ghc/common-make-native-bignum.nix
index 03ad68c392a1..d3573cc3a522 100644
--- a/pkgs/development/compilers/ghc/common-make-native-bignum.nix
+++ b/pkgs/development/compilers/ghc/common-make-native-bignum.nix
@@ -364,7 +364,44 @@ stdenv.mkDerivation (
           else
             ./Cabal-3.2-3.4-paths-fix-cycle-aarch64-darwin.patch
         )
-      ];
+      ]
+      # Before GHC 9.6, GHC, when used to compile C sources (i.e. to drive the CC), would first
+      # invoke the C compiler to generate assembly and later call the assembler on the result of
+      # that operation. Unfortunately, that is brittle in a lot of cases, e.g. when using mismatched
+      # CC / assembler (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12005). This issue
+      # does not affect us. However, LLVM 18 introduced a check in clang that makes sure no
+      # non private labels occur between .cfi_startproc and .cfi_endproc which causes the
+      # assembly that the same version (!) of clang generates from rts/StgCRun.c to be rejected.
+      # This causes GHC to fail compilation on mach-o platforms ever since we upgraded to
+      # LLVM 19.
+      #
+      # clang compiles the same file without issues whithout the roundtrip via assembly. Thus,
+      # the solution is to backport those changes from GHC 9.6 that skip the intermediate
+      # assembly step.
+      #
+      # https://gitlab.haskell.org/ghc/ghc/-/issues/25608#note_622589
+      # https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6877
+      ++ (
+        if lib.versionAtLeast version "9.4" then
+          [
+            # Need to use this patch so the next one applies, passes file location info to the cc phase
+            (fetchpatch {
+              name = "ghc-add-location-to-cc-phase.patch";
+              url = "https://gitlab.haskell.org/ghc/ghc/-/commit/4a7256a75af2fc0318bef771a06949ffb3939d5a.patch";
+              hash = "sha256-DnTI+i1zMebeWvw75D59vMaEEBb2Nr9HusxTyhmdy2M=";
+            })
+            # Makes Cc phase directly generate object files instead of assembly
+            (fetchpatch {
+              name = "ghc-cc-directly-emit-object.patch";
+              url = "https://gitlab.haskell.org/ghc/ghc/-/commit/96811ba491495b601ec7d6a32bef8563b0292109.patch";
+              hash = "sha256-G8u7/MK/tGOEN8Wxccxj/YIOP7mL2G9Co1WKdHXOo6I=";
+            })
+          ]
+        else
+          [
+            # TODO(@sternenseemann): backport changes to GHC < 9.4 if possible
+          ]
+      );
 
     postPatch = "patchShebangs .";