Provide GHC builds with dwarf support enabled

[nh2]

Debugging Haskell programs is much easier when GHC's DWARF support is enabled.

According to @bgamari, this requires ./configure --enable-dwarf-unwind when building GHC, and a libdw dependency.

---

For the beginning, this should be an optional setting for nixpkgs's GHCs.

But for later, it may make sense to discuss whether this should be the default.

According to @bgamari, there are no drawbacks beyond larger libraries being installed. There are no run-time overheads when -g isn't given for the final linked Haskell program.

This means that download size of Haskell development libraries would increase, but the size of Haskell-built executables would not (neither would closure size as statish-built Haskell exes don't depend on GHC or Haskell libraries). Since developers are most likely very interested in the debugging facilities that DWARF support delivers, this is likely something we want to enable by default.

[nh2]

Here's an example of how to do it for 8.2.2:

diff --git a/pkgs/development/compilers/ghc/8.2.2.nix b/pkgs/development/compilers/ghc/8.2.2.nix
index dcc2852a341..05a483109c3 100644
--- a/pkgs/development/compilers/ghc/8.2.2.nix
+++ b/pkgs/development/compilers/ghc/8.2.2.nix
@@ -3,11 +3,14 @@
 
 # build-tools
 , bootPkgs, alex, happy, hscolour
-, autoconf, autoreconfHook, automake, coreutils, fetchurl, fetchpatch, perl, python3, sphinx
+, autoconf, autoreconfHook, automake, coreutils, fetchurl, fetchpatch, perl, python3, sphinx, elfutils
 , runCommand
 
 , libffi, libiconv ? null, ncurses
 
+, enableDwarf ? false
+
 , useLLVM ? !targetPlatform.isx86
 , # LLVM is conceptually a run-time-only depedendency, but for
   # non-x86, we need LLVM to bootstrap later stages, so it becomes a
@@ -61,6 +64,7 @@ let
   # Splicer will pull out correct variations
   libDeps = platform: [ ncurses ]
     ++ stdenv.lib.optional (!enableIntegerSimple) gmp
+    ++ stdenv.lib.optional enableDwarf elfutils # elfutils provides libdw
     ++ stdenv.lib.optional (platform.libc != "glibc") libiconv;
 
   toolsForTarget =
@@ -96,6 +100,11 @@ stdenv.mkDerivation rec {
       url = "https://github.com/shlevy/ghc/commit/fec1b8d3555c447c0d8da0e96b659be67c8bb4bc.patch";
       sha256 = "1lyysz6hfd1njcigpm8xppbnkadqfs0kvrp7s8vqgb38pjswj5hg";
     })
+    ++ stdenv.lib.optional enableDwarf
+    (fetchpatch { # Backport of https://phabricator.haskell.org/D5424 to fail loudly if libdw can't be found
+      url = "https://git.haskell.org/ghc.git/commitdiff_plain/cb882fc993b4972f7f212b291229ef9e9ade0af9";
+      sha256 = "0xmn57fr8cdxvnsc2ykdkcxflz3gkcirih6ca33d4b9hma8nfsrk";
+    })
     ++ stdenv.lib.optional stdenv.isDarwin ./backport-dylib-command-size-limit.patch;
 
   postPatch = "patchShebangs .";
@@ -135,6 +144,8 @@ stdenv.mkDerivation rec {
     "--with-curses-includes=${ncurses.dev}/include" "--with-curses-libraries=${ncurses.out}/lib"
   ] ++ stdenv.lib.optional (targetPlatform == hostPlatform && ! enableIntegerSimple) [
     "--with-gmp-includes=${gmp.dev}/include" "--with-gmp-libraries=${gmp.out}/lib"
+  ] ++ stdenv.lib.optional enableDwarf [
+    "--enable-dwarf-unwind"
   ] ++ stdenv.lib.optional (targetPlatform == hostPlatform && hostPlatform.libc != "glibc") [
     "--with-iconv-includes=${libiconv}/include" "--with-iconv-libraries=${libiconv}/lib"
   ] ++ stdenv.lib.optionals (targetPlatform != hostPlatform) [

The added fetchpatch won't be necessary for GHC >= 8.8.

[nh2]

The fetched patch here is buggy due to autoconf not telling us that there's a syntax error.

See #ghc discussion:

nh2: bgamari: when I compile ghc with --enable-dwarf-unwind and get checking for dwfl_attach_state in -ldw... yes, but ghc --info still shows ("RTS expects libdw","NO"), is that OK?
nh2: I built a dwarf-enabled ghc on nix and got the output but the final binary still says NO
bgamari: nh2, doesn't sound good
bgamari: hmm
nh2: bgamari: I also cherry-picked the patch from 3 days ago, it complained as expected when elfutils wasn't there, hmm
nh2: bgamari: this is 8.2.2 btw, is there anything special to this one that might make it not work?
bgamari: not that I can recall
nh2: bgamari: this file https://github.com/ghc/ghc/blob/ghc-8.2/compiler/ghc.mk#L106 where does that generated into? I want to check in the build dir what it says there
nh2: bgamari: I have this:
nh2: /tmp/nix-build-ghc-8.2.2.drv-0/ghc-8.2.2/compiler/stage1/build/Config.hs:cGhcRtsWithLibdw = False
nh2: should it be False for stage1 or should it already be True here if I pass --enable-dwarf-unwind?
bgamari: nh2, iirc the relevant files are mk/config.mk.in and settings.in
harpocrates: nh2: just looking at the code, --enable-dwarf-unwind wont necessarily make "GhcRtsWithLibdw=YES"
harpocrates: See https://github.com/ghc/ghc/blob/699e507237ccda65fe9f37651d2358129390e2de/mk/config.mk.in#L409
bgamari: right
harpocrates: (And yeah - maybe that should lead to some warning)
bgamari: T8353 seems to fail rather strangely on my machine
bgamari: some fraction of the time part of the error message just vanishes
nh2: uh, there's UseLibdw='NO' in my config.log, how comes?
nh2: harpocrates: I don't get it, I have your patch picked, it says checking for dwfl_attach_state in -ldw... yes, and nevertheless I have UseLibdw=NO
harpocrates: Yeah, I'm looking at the code trying to figure out how this could happen
nh2: harpocrates: I see there's [UseLibdw=NO] before the closing ) of AC_ARG_ENABLE(..., what does that do? Is it an argument to AC_ARG_ENABLE?
bgamari: nh2, the joy of autoconf :)
harpocrates: nh2: yeah, that should be the case for if "--enable-dwarf-unwind" is not specified
nh2: bgamari: I think autoconf is total garbage btw, it makes problems in every project I've been part of, it never works (because one cannot use it correctly) and is such a time sink that it would have been faster to write custom feature detection scripts almost every time :/
nh2: harpocrates: does that not need a comma before it?
nh2: harpocrates: the other uses of AC_ARG_ENABLE have two , between the ()
harpocrates: Oh gosh.
nh2: bgamari: that's what I mean

There's a , missing at the end of ghc/ghc@cb882fc#diff-67e997bcfdac55191033d57a16d1408aR1253.

autoconf happily accepts the syntax error and continues with UseLibdw='YES' in config.log.

[nh2]

PR at #52255

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/ghc-with-libdw-support/6654/1

[nh2]

Also see this new blog post series about DWARF support and usage in GHC by @bgamari:

http://www.well-typed.com/blog/2020/04/dwarf-1/

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/ghc-with-libdw-support/6654/2

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[nh2]

Still valid

[domenkozar]

Dwarf is now enabled on ghcHEAD, but that needs to be backported to GHC 8.10.x

[stale]

I marked this as stale due to inactivity. → More info