Strategy for Snaps with Debugging Symbols

[Dmitrii Shcherbakov]

Just wanted to add that if we went for the approach where we replace
an application with its debug version, another issue is that complex
applications may behave differently depending on added instrumentation
in a debug build.

For example, if you added debugging code that slows down an
application in general it may stop triggering race conditions or
certain code paths.

In other words, there is a difference between running a 'debugging
build' and a 'release build with some debugging symbols loaded'.
Best Regards,
Dmitrii Shcherbakov


Dmitrii Shcherbakov  | Canonical
Field Software Engineer
dmitrii.shcherbakov at canonical.com
IRC (freenode): Dmitrii-Sh


On Tue, Mar 28, 2017 at 10:44 AM, Christian Ehrhardt
<christian.ehrhardt at canonical.com> wrote:
>
> 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