Strategy for Snaps with Debugging Symbols

Christian Ehrhardt 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
> 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



More information about the Snapcraft mailing list