On Tue, Mar 28, 2017 at 8:13 AM, Alfonso Sanchez-Beato < alfonso.sanchez-be...@canonical.com> wrote:
> > One idea for snaps is to use -dbg tracks which are going to contain snaps > > with embedded debugging symbols. Of course, some snaps may contain a > number > > of services so you'd have to customize your build process and create > > additional automation around snapcraft to make it more manageable. > > > > I would love to see this, it would ease a lot the debugging pain for snaps. > IMHO using a debugging track makes lots of sense, provided gdbserver/gdb in > Ubuntu Core can be configured to find the symbols automatically. It might come down to teach gdb and co certain path. On the classic packaging is is about /usr/lib/debug prefixing the canonical path of the binary. So lib and lib+debug symbols are: $ file /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, not stripped $ file /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, stripped The matching flag build-id in there make sure programs can check they match and pick it up automatically [1]. Now a binary of a snap appears like in a versioned path, but there is the current link which should be stable. So the binary of e.g. the latest vlc snap is always in: /snap/vlc/current/bin/vlc That would mean if there would be symbols at "/usr/lib/debug/snap/vlc/current/bin/vlc.debug" would likely work as of today in case you want to link yourself something up. Actually I think it would be fair that snaps could "own" the snap subdir of the global debug dir being "/usr/lib/debug/snap" and mirror the snap layout there but populated with the debug symbols. Also I agree that this should not be a manual task of some sort, just like the .deb packaging an optional -dbg snap or such could fall out of any build that does contain the non-stripped binaries. All that is true for a classic gdb, but a snapped gdb will itself run confined and in its local path to some extend - that has to be considered as well going forward. Also the whole command semantic has to be sound and tasteful for those who want to use it, while not distracting non debugging snap users too much. As the debug snaps clearly have a reduced subset of actions (e.g. no interfaces) maybe one option would be to hide that reduced subset all behind one subcommand like: "snap dbg [find|list|install|...]" ? [1]: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft