| Message ID | 20210517185001.123609-1-krzysztof.kozlowski@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | [UNSTABLE,v2] UBUNTU: [Packaging] Build and include GDB Python scripts into debug packages | expand |
Hi, On Mon, May 17, 2021 at 7:50 PM Krzysztof Kozlowski <krzysztof.kozlowski@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? Normally, when running under gdb it has autoload functionality of loading auxiliary scripts. Ie. python3.9-gdb for the interpreter ships the below /usr/share/gdb/auto-load/usr/bin/python3.9-dbg-gdb.py Would it not make more sense to ship the gdb kernel scripts under like /usr/share/gdb/auto-load/boot/vmlinuz-X.Y.Z-gdb.py ? Or do they at all cannot work with gdb auto-load functionality? Can we store them somewhere by build-id note (if that is at all helpful)? Where do other distributions ship these gdb scripts? Cause i have not seen /usr/lib/debug/share before. > BugLink: https://bugs.launchpad.net/bugs/1928715 > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> > > --- > > Changes since v1 (RFC): > 1. Add a comment inside .mk. > 2. More tests. > --- > debian/rules.d/2-binary-arch.mk | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk > index 0b008df5a853..d297dc84ff48 100644 > --- a/debian/rules.d/2-binary-arch.mk > +++ b/debian/rules.d/2-binary-arch.mk > @@ -49,6 +49,13 @@ $(stampdir)/stamp-build-%: $(stampdir)/stamp-prepare-% > @echo Debug: $@ build_image $(build_image) bldimg $(bldimg) > $(build_cd) $(kmake) $(build_O) $(conc_level) $(bldimg) modules $(if $(filter true,$(do_dtbs)),dtbs) > > +ifneq ($(skipdbg),true) > + # The target scripts_gdb is part of "all", so we need to call it manually > + if grep -q CONFIG_GDB_SCRIPTS=y $(builddir)/build-$*/.config; then \ > + $(build_cd) $(kmake) $(build_O) $(conc_level) scripts_gdb ; \ > + fi > +endif > + > @touch $@ > > define build_dkms_sign = > @@ -295,6 +302,12 @@ ifneq ($(skipdbg),true) > # Debug image is simple > install -m644 -D $(builddir)/build-$*/vmlinux \ > $(dbgpkgdir)/usr/lib/debug/boot/vmlinux-$(abi_release)-$* > + if [ -d $(builddir)/build-$*/scripts/gdb/linux ]; then \ > + install -m644 -D $(builddir)/build-$*/vmlinux-gdb.py \ > + $(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/vmlinux-gdb.py; \ > + install -m644 -D $(builddir)/build-$*/scripts/gdb/linux/* \ > + --target-directory=$(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/scripts/gdb/linux; \ > + fi > $(build_cd) $(kmake) $(build_O) modules_install $(vdso) \ > INSTALL_MOD_PATH=$(dbgpkgdir)/usr/lib/debug > # Add .gnu_debuglink sections only after all/DKMS modules are built. > -- > 2.27.0 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 5/17/21 9:37 PM, Dimitri John Ledkov wrote: > Hi, > > On Mon, May 17, 2021 at 7:50 PM Krzysztof Kozlowski > <krzysztof.kozlowski@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? > > Normally, when running under gdb it has autoload functionality of > loading auxiliary scripts. > > Ie. python3.9-gdb for the interpreter ships the below > /usr/share/gdb/auto-load/usr/bin/python3.9-dbg-gdb.py > > Would it not make more sense to ship the gdb kernel scripts under like > > /usr/share/gdb/auto-load/boot/vmlinuz-X.Y.Z-gdb.py ? Or do they at all > cannot work with gdb auto-load functionality? Can we store them > somewhere by build-id note (if that is at all helpful)? > > Where do other distributions ship these gdb scripts? Cause i have not > seen /usr/lib/debug/share before. if you don't configure gdb explicitly with --with-auto-load-dir=PATH directories from which to load auto-loaded scripts [$debugdir:$datadir/auto-load] /usr/share/gdb/auto-load would be the default. So /usr/share/gdb/auto-load/boot/vmlinuz-X.Y.Z-gdb.py sounds sensible. However I didn't check if gdb is smart enough to do the auto-loading for non ELF binaries. Basing the lookup on build id's might be possible, would need an upstream patch. However you can't easily determine anymore which autoload capbilities you have installed. Having a real name in the auto-load directory is much more descriptive. Matthias >> BugLink: https://bugs.launchpad.net/bugs/1928715 >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> >> >> --- >> >> Changes since v1 (RFC): >> 1. Add a comment inside .mk. >> 2. More tests. >> --- >> debian/rules.d/2-binary-arch.mk | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk >> index 0b008df5a853..d297dc84ff48 100644 >> --- a/debian/rules.d/2-binary-arch.mk >> +++ b/debian/rules.d/2-binary-arch.mk >> @@ -49,6 +49,13 @@ $(stampdir)/stamp-build-%: $(stampdir)/stamp-prepare-% >> @echo Debug: $@ build_image $(build_image) bldimg $(bldimg) >> $(build_cd) $(kmake) $(build_O) $(conc_level) $(bldimg) modules $(if $(filter true,$(do_dtbs)),dtbs) >> >> +ifneq ($(skipdbg),true) >> + # The target scripts_gdb is part of "all", so we need to call it manually >> + if grep -q CONFIG_GDB_SCRIPTS=y $(builddir)/build-$*/.config; then \ >> + $(build_cd) $(kmake) $(build_O) $(conc_level) scripts_gdb ; \ >> + fi >> +endif >> + >> @touch $@ >> >> define build_dkms_sign = >> @@ -295,6 +302,12 @@ ifneq ($(skipdbg),true) >> # Debug image is simple >> install -m644 -D $(builddir)/build-$*/vmlinux \ >> $(dbgpkgdir)/usr/lib/debug/boot/vmlinux-$(abi_release)-$* >> + if [ -d $(builddir)/build-$*/scripts/gdb/linux ]; then \ >> + install -m644 -D $(builddir)/build-$*/vmlinux-gdb.py \ >> + $(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/vmlinux-gdb.py; \ >> + install -m644 -D $(builddir)/build-$*/scripts/gdb/linux/* \ >> + --target-directory=$(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/scripts/gdb/linux; \ >> + fi >> $(build_cd) $(kmake) $(build_O) modules_install $(vdso) \ >> INSTALL_MOD_PATH=$(dbgpkgdir)/usr/lib/debug >> # Add .gnu_debuglink sections only after all/DKMS modules are built. >> -- >> 2.27.0 >> >> >> -- >> kernel-team mailing list >> kernel-team@lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/kernel-team > > >
On 17/05/2021 15:37, Dimitri John Ledkov wrote: > Hi, > > On Mon, May 17, 2021 at 7:50 PM Krzysztof Kozlowski > <krzysztof.kozlowski@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. > > 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? Best regards, Krzysztof
On 5/18/21 12:51 PM, Krzysztof Kozlowski 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@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. > >> >> 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? No, symbols are loaded automatically by gdb, if they are found.
On Tue, May 18, 2021 at 11:51 AM Krzysztof Kozlowski <krzysztof.kozlowski@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@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. > > > > 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.
On 18/05/2021 06:53, Matthias Klose wrote: > On 5/18/21 12:51 PM, Krzysztof Kozlowski 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@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. >> >>> >>> 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? > > No, symbols are loaded automatically by gdb, if they are found. They did not in my case, so maybe my command was wrong - how can you load them automatically? Different thing is that they should not be loaded automatically because they will kill gdb (by OOM) on smaller systems, like some cloud instances. Best regards, Krzysztof
On Tue, May 18, 2021 at 12:09 PM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > > On 18/05/2021 06:53, Matthias Klose wrote: > > On 5/18/21 12:51 PM, Krzysztof Kozlowski 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@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. > >> > >>> > >>> 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? > > > > No, symbols are loaded automatically by gdb, if they are found. > > They did not in my case, so maybe my command was wrong - how can you > load them automatically? > > Different thing is that they should not be loaded automatically because > they will kill gdb (by OOM) on smaller systems, like some cloud instances. One should start a gdb server on the small system, connect to it from the large machine and have the large machine load all the things. Because yes, it is usually impossible to debug small machines in place. If symbols did not get autoloaded, there must be some mismatch somewhere. The expectation is, if you have matching things installed, launching gdb alone should be enough without explicitly setting or asking for anything. What steps were you doing to debug things / how to reproduce the usability issue you had?
On 18/05/2021 07:12, Dimitri John Ledkov wrote: > On Tue, May 18, 2021 at 12:09 PM Krzysztof Kozlowski > <krzysztof.kozlowski@canonical.com> wrote: >> >> On 18/05/2021 06:53, Matthias Klose wrote: >>> On 5/18/21 12:51 PM, Krzysztof Kozlowski 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@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. >>>> >>>>> >>>>> 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? >>> >>> No, symbols are loaded automatically by gdb, if they are found. >> >> They did not in my case, so maybe my command was wrong - how can you >> load them automatically? >> >> Different thing is that they should not be loaded automatically because >> they will kill gdb (by OOM) on smaller systems, like some cloud instances. > > One should start a gdb server on the small system, connect to it from > the large machine and have the large machine load all the things. > Because yes, it is usually impossible to debug small machines in > place. This is different use case. I am talking about debugging existing system and the symbols should not be autoloaded for such case. Otherwise one is unable to even start gdb. > If symbols did not get autoloaded, there must be some mismatch > somewhere. The expectation is, if you have matching things installed, > launching gdb alone should be enough without explicitly setting or > asking for anything. > > What steps were you doing to debug things / how to reproduce the > usability issue you had? The regular way of debugging current kernel, so: gdb /boot/vmlinuz /proc/kcore But if you have other way which always loads symbols, please share your command. Best regards, Krzysztof
On 18/05/2021 07:07, Dimitri John Ledkov wrote: > On Tue, May 18, 2021 at 11:51 AM Krzysztof Kozlowski > <krzysztof.kozlowski@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@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). Best regards, Krzysztof
On Tue, May 18, 2021 at 12:41 PM Krzysztof Kozlowski <krzysztof.kozlowski@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@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@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
diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk index 0b008df5a853..d297dc84ff48 100644 --- a/debian/rules.d/2-binary-arch.mk +++ b/debian/rules.d/2-binary-arch.mk @@ -49,6 +49,13 @@ $(stampdir)/stamp-build-%: $(stampdir)/stamp-prepare-% @echo Debug: $@ build_image $(build_image) bldimg $(bldimg) $(build_cd) $(kmake) $(build_O) $(conc_level) $(bldimg) modules $(if $(filter true,$(do_dtbs)),dtbs) +ifneq ($(skipdbg),true) + # The target scripts_gdb is part of "all", so we need to call it manually + if grep -q CONFIG_GDB_SCRIPTS=y $(builddir)/build-$*/.config; then \ + $(build_cd) $(kmake) $(build_O) $(conc_level) scripts_gdb ; \ + fi +endif + @touch $@ define build_dkms_sign = @@ -295,6 +302,12 @@ ifneq ($(skipdbg),true) # Debug image is simple install -m644 -D $(builddir)/build-$*/vmlinux \ $(dbgpkgdir)/usr/lib/debug/boot/vmlinux-$(abi_release)-$* + if [ -d $(builddir)/build-$*/scripts/gdb/linux ]; then \ + install -m644 -D $(builddir)/build-$*/vmlinux-gdb.py \ + $(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/vmlinux-gdb.py; \ + install -m644 -D $(builddir)/build-$*/scripts/gdb/linux/* \ + --target-directory=$(dbgpkgdir)/usr/lib/debug/share/$(abi_release)-$*/scripts/gdb/linux; \ + fi $(build_cd) $(kmake) $(build_O) modules_install $(vdso) \ INSTALL_MOD_PATH=$(dbgpkgdir)/usr/lib/debug # Add .gnu_debuglink sections only after all/DKMS modules are built.
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. BugLink: https://bugs.launchpad.net/bugs/1928715 Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> --- Changes since v1 (RFC): 1. Add a comment inside .mk. 2. More tests. --- debian/rules.d/2-binary-arch.mk | 13 +++++++++++++ 1 file changed, 13 insertions(+)