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

Krzysztof Kozlowski krzysztof.kozlowski at canonical.com
Tue May 18 11:18:13 UTC 2021


On 18/05/2021 07:12, Dimitri John Ledkov wrote:
> On Tue, May 18, 2021 at 12:09 PM Krzysztof Kozlowski
> <krzysztof.kozlowski at 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 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.
>>>>
>>>>>
>>>>> 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



More information about the kernel-team mailing list