libllvm/libclang debug symbol in llvmPackages

[ksyx]

Describe the bug

LLVM and clang packages are tough on hardware resources to build and the debug symbols of these libraries are essential when developing things linked to them, but there does not seem to be having a debug output from these derivations, and the fact that Release being built by default possibly eliminated debug symbols in them.

Steps To Reproduce

Steps to reproduce the behavior:

1. For a flake with the followings:

   inputs = {
   nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";
   };
   
   outputs = { self, nixpkgs, ... }: let
   system = "x86_64-linux";
   in {
   devShells."${system}".default = let
     pkgs = import nixpkgs { inherit system; };
   in pkgs.mkShell.override {
     stdenv = pkgs.stdenvAdapters.keepDebugInfo pkgs.llvmPackages_17.stdenv; } {
     packages = with pkgs; [
       gdb
     ];
   };
   };

2. Inspecting the wrapper as pointed to which clang with ldd gives paths to libLLVM.so and libclang-cpp.so
3. Running gdb on these shared libraries gives (No debugging symbols found in /nix/store/ax9wbqknwawnl21kvkp8l6jn2r6q0l90-llvm-17.0.6-lib/lib/libLLVM-17.so) and (No debugging symbols found in /nix/store/wxxgsgjxbnkkyczgf8lkbfrsqiywm8bi-clang-17.0.6-lib/lib/libclang-cpp.so.17), while doing the same on a manually compiled version does not.

Expected behavior

Build with debug symbols by default and leave to downstream to strip it, possibly by using RelWithDebInfo build type, preferably in the form of a separate debug output that can be used by debuginfod.

Screenshots

N/A

Additional context

I tried some manual (and ugly) override in an hope to solve this myself, as in the follows. However, the build failed in install phase with this kinda hardcoding on file name. I am aware that the llvm package has a parameter of debugVersion, but there is not one for the clang package and some similar lines present in the clang packages as well, so would it be better if lib.strings.toLower cmakeBuildType is used in place of these? (given that CMake just seems to be doing that upon quickly checking its source)

devShells."${system}".default = let
      pkgs = import nixpkgs {
        inherit system;
      };
      llvm = let llvmPkg = pkgs.llvmPackages_17;
        in llvmPkg // {
          libllvm = pkgs.enableDebugging (llvmPkg.libllvm.overrideAttrs (
            finalAttrs: prevAttrs: {
              cmakeBuildType = "RelWithDebInfo";
              cmakeFlags = prevAttrs.cmakeFlags ++ [
                "-DLLVM_TARGETS_TO_BUILD=X86"
              ];}));};

https://github.com/NixOS/nixpkgs/blob/6f6c45b5134a8ee2e465164811e451dcb5ad86e3/pkgs/development/compilers/llvm/common/llvm/default.nix#L390-L392 https://github.com/NixOS/nixpkgs/blob/6f6c45b5134a8ee2e465164811e451dcb5ad86e3/pkgs/development/compilers/llvm/common/clang/default.nix#L102-L106

Notify maintainers

@RossComputerGuy @sternenseemann Thanks!

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.35, NixOS, 24.05 (Uakari), 24.05.20240626.89c4987`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/f0ddmw6s86y567yg06h5019z72szbzch-source`

---

Add a :+1: reaction to issues you find important.

[RossComputerGuy]

CC @NixOS/llvm

Even though it does take significant resources to build LLVM, I don't think shipping debug symbols by default is a good idea.

[ksyx]

Yes as mentioned it might be desirable to use separateDebugInfo to have a separate debug output that can be downloaded on demand by tools like nixseparatedebuginfod, as described in https://nixos.wiki/wiki/Debug_Symbols#Packages_with_a_debug_output.

Thanks for the super fast reply btw

[alyssais]

I think we absolutely should, using separateDebugInfo.

[RossComputerGuy]

Ok yeah, looking into it more I agree. I though this was meaning debug symbols straight into the binary. If it's separate then that'll be a separate derivation and we should be good there.

[alyssais]

It will be a separate output, not a separate derivation.

[RossComputerGuy]

I meant output not derivation but yeah, this isn't bad.