Strategy for Snaps with Debugging Symbols
christian.ehrhardt at canonical.com
Tue Mar 28 07:44:41 UTC 2017
On Tue, Mar 28, 2017 at 8:13 AM, Alfonso Sanchez-Beato <
alfonso.sanchez-beato at 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
> > 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:
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,
The matching flag build-id in there make sure programs can check they match
and pick it up automatically .
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:
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|...]" ?
Software Engineer, Ubuntu Server
More information about the Snapcraft