[Nix-dev] Debugging Symbols

[Kevin Cox]

On Mon, 2016-02-15 at 17:45 +0100, Eelco Dolstra wrote:
> Hi,
> 
> On 15/02/16 15:43, Kevin Cox wrote:
> 
> > The solution is obviously seperate debug files
> > 
> > l> which
> > allows the debugging symbols to be kept separate from the binary
> > itself. I see
> > that there was an earlier attempt but it appears to have failed due
> > to profile
> > linking issues
> > (https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/config/
> > debug-info.nix).
> 
> Not sure I understand the problem. That *is* the supported way on
> NixOS to get
> debug symbols, and AFAIK it works. What's the profile linking issue
> you refer to?
Sorry, I guess I was misunderstanding the comments. I interpreted it as
it was disabled due to not being able to create a symlink forest for
/lib/debug/.build-id when /lib is enabled. But reading the file again
it looks like this is a work-around for that issue?
> > 
> > I also think that this approach isn't ideal because it requires the program to
> > be "installed" which is generally not the case for my system services.
> > 

> 
> 
> Yes, currently it only includes debug info for packages in
> environment.systemPackages, but this could fairly easily be extended to packages
> in the path of systemd services, or maybe even all packages in the system
> closure. You can also explicitly include debug symbols, e.g.
> 
>   environment.systemPackages = [ hello.debug ];
> 

Ok, if this is working it isn't a bad solution. Is there any way to
automatically link all of the dependant packages into the environment?
Because often you will want things like libc and other used libraries
as well. Or is this currently a manual process.
> (At FOSDEM, Mark Wielaard [1] mentioned that we should really have a little FUSE
> filesystem to make a repository of *all* debug symbols available to GDB over the
> network, so you don't have to install them manually. That would be really neat...)
> 
> [1]
> 
https://fosdem.org/2016/schedule/event/where_are_your_symbols_debuginfo_and_sources/

That would be really cool but considerably more work. We would also
have to figure out how to map a build-id to a store path. An external
index wouldn't be super pretty but it would work.
Sorry for the noise then, I didn't realize that this was working.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160215/8f992f1f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160215/8f992f1f/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5658 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160215/8f992f1f/attachment-0003.bin