[UNSTABLE][PATCH v2] UBUNTU: [Packaging] Build and include GDB Python scripts into debug packages

[Dimitri John Ledkov]

On Tue, May 18, 2021 at 12:41 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On 18/05/2021 07:07, Dimitri John Ledkov wrote:
> > On Tue, May 18, 2021 at 11:51 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski at canonical.com> wrote:
> >>
> >> On 17/05/2021 15:37, Dimitri John Ledkov wrote:
> >>> Hi,
> >>>
> >>> On Mon, May 17, 2021 at 7:50 PM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski at canonical.com> wrote:
> >>>>
> >>>> The kernel comes with useful GDB debugging scripts/commands (enabled
> >>>> with CONFIG_GDB_SCRIPTS), however these are built either with "all" make
> >>>> target or with "scripts_gdb".  Build these in
> >>>> "$(stampdir)/stamp-build-%" target and package in "install-%" under
> >>>> /usr/lib/debug/share.
> >>>>
> >>>
> >>> I'm still not too sure about this location. Where did it come from?
> >>
> >> It came from other files in dbgsym package.
> >>
> >
> > Sure but /usr/lib/debug/$PATH should be a debug edition of the same
> > thing, that is available from $PATH. E.g.
> > usr/lib/debug/usr/sbin/pfqueue is a debug version of the otherwise
> > standard build of /usr/sbin/pfqueue.
> >
> > /usr/lib/debug/share is not a location that gdb has as a built-in
> > allowed directory to load plugins from. gdb only reads helper scripts
> > (that match the path of the thing it is debugging) from
> > /usr/share/gdb/auto-load/${PATH}-gdb.py
> >
> > And these are gdb specific scripts / plugins, that should be put in a
> > safe-load directory that gdb knows how to load from when debugging a
> > kernel. Otherwise it will be very hard to use them from gdb, and
> > require a new random directory to use these. That's not discoverable.
>
> It does not have to be discoverable but simply usable. Anyway,
> /usr/share is better place.
>
> >
> >>>
> >>> Normally, when running under gdb it has autoload functionality of
> >>> loading auxiliary scripts.
> >>
> >> I am not sure if this is good idea to add them to autoload. They have no
> >> meaning outside of Linux kernel so why they should be present on each
> >> gdb run? Anyway user will have to load symbols separately, so why not
> >> loading scripts as well?
> >
> > auto-load is smart, it loads things by path for the thing one is
> > debugging. Thus when debugging $kernel it auto-loads $kernel-gdb.py
> > script; when debugging python3.9 it auto-loads python3.9-gdb.py
> > script, etc. As long as these scripts are shipped in the path that gdb
> > expects.
>
> That's not smart at all, that's simply loading by matching name. Here
> you have one binary - /boot/vmlinuz - and multiple debugging symbols
> (5.4.0-1047-aws, 5.4.0-1048-aws, 5.4.0-1049-aws).

/boot/vmlinuz is not a binary which we ever install or boot or ship in
any .deb, because that would prevent us from ever installing more than
one kernel in parallel.

/boot/vmlinuz is a symlink only, optional, and is not usually used by
bootloaders on installed systems. I.e. updating /boot/vmlinuz to a
different kernel will not cause the system to boot it by default.

The exceptions to above are cdroms & s390x where we static bootloader
configurations referencing the symlink name.

$ ls -latr /boot/vmlinuz
lrwxrwxrwx 1 root root 24 May 12 06:43 /boot/vmlinuz -> vmlinuz-5.8.0-53-generic

Thus when doing gdb I would expect one to do it against
/boot/vmlinuz-$(uname -r) => since the kernel one has booted might not
be what /boot/vmlinuz points at.

And hence the autoload script should be named after
/boot/vmlinuz-$(uname -r)-gdb.py

-- 
Regards,

Dimitri.