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

[Krzysztof Kozlowski]

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).


Best regards,
Krzysztof