1. 5

  2. 4

    Debug symbols are one of my bigger concerns with Nix. It is a fairly hard problem.

    • The built packages don’t know their debuginfo output. You need to have access to the drv. This means that you can’t always look up the debug info for a path.
    • Enabling debug info for your system is only for “installed” packages. It doesn’t help for services or that docker container I just built for kube.

    Ideally the soultion would:

    • For any path or coredump find any debug info that I have installed.
    • Allow me to fetch that from a binary cache if I don’t have it locally.
    • Users would have the option to automatically download all debug symbols for the packages they download, or they can be lazy loaded by the debugger. In prod you wouldn’t have to download them at all.

    I think the current state-of-the-art is https://github.com/edolstra/dwarffs but the biggest limitation there is that it only really works for cache.nixos.org. The upload process is out-of-band and it can’t use locally cached symbols (as it doesn’t know which are the relevant ones)

    1. 1

      Thanks for writing this post. Was an informative read.

      …was trying to produce an invoice… some combination of dates on the invoice resulted in a segfault

      The frustrating experience of Linux strikes again. Just when one wants to get stuff done, he is hit by the most obscure bugs that the often non-existent test-suite of the combination of upstream+package didn’t catch. The rest of the story is the usual rabit-hole: The IRC/Matrix/Github Issues/Mailing List dance we are all familiar with.

      1. 2

        I believe that’s a general software problem, as long as there is code stuff is gonna break. At least this time I was happy to use it as a starting point to learn a thing or five and it validated my choice of using nix, because it was super easy to upgrade gnucash upstream and use the newer version locally before it even merged in nixpkgs.