Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
that provide OS awareness for debuggers and allows for debugging of a
variety of data structures (lists, timers, radix tree, mapletree, etc.)
as well as subsystems (clocks, devices, classes, busses, etc.).

These scripts are typically maintained in isolation from the subsystem
that they parse the data structures and symbols of, which can lead to
people playing catch up with fixing bugs or updating the script to work
with updates made to the internal APIs/objects etc. Here are some
recents examples:

https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/

This patch series is intentionally split such that each subsystem
maintainer can decide whether to accept the extra
review/maintenance/guidance that can be offered when GDB scripts are
being updated or added.

Thanks!

Florian Fainelli (16):
  MAINTAINERS: Include clk.py under COMMON CLK FRAMEWORK entry
  MAINTAINERS: Include device.py under DRIVER CORE entry
  MAINTAINERS: Include genpd.py under GENERIC PM DOMAINS entry
  MAINTAINERS: Include radixtree.py under GENERIC RADIX TREE entry
  MAINTAINERS: Include interrupts.py under IRQ SUBSYSTEM entry
  MAINTAINERS: Include kasan.py under KASAN entry
  MAINTAINERS: Include mapletree.py under MAPLE TREE entry
  MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry
  MAINTAINERS: Include modules.py under MODULE SUPPORT entry
  MAINTAINERS: Include cpus.py under PER-CPU MEMORY ALLOCATOR entry
  MAINTAINERS: Include timerlist.py under POSIX CLOCKS and TIMERS entry
  MAINTAINERS: Include dmesg.py under PRINTK entry
  MAINTAINERS: Include proc.py under PROC FILESYSTEM entry
  MAINTAINERS: Include vmalloc.py under VMALLOC entry
  MAINTAINERS: Include xarray.py under XARRAY entry
  MAINTAINERS: Include vfs.py under FILESYSTEMS entry

 MAINTAINERS | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

-- 
2.43.0

* Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
> that provide OS awareness for debuggers and allows for debugging of a
> variety of data structures (lists, timers, radix tree, mapletree, etc.)
> as well as subsystems (clocks, devices, classes, busses, etc.).
> 
> These scripts are typically maintained in isolation from the subsystem
> that they parse the data structures and symbols of, which can lead to
> people playing catch up with fixing bugs or updating the script to work
> with updates made to the internal APIs/objects etc. Here are some
> recents examples:
> 
> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
> 
> This patch series is intentionally split such that each subsystem
> maintainer can decide whether to accept the extra
> review/maintenance/guidance that can be offered when GDB scripts are
> being updated or added.

I don't see why you think it was okay to propose this in the way you
have gone about it.  Looking at the mailing list, you've been around for
a while.

The file you are telling me about seems to be extremely new and I needed
to pull akpm/mm-new to discover where it came from.. because you never
Cc'ed me on the file you are asking me to own.

I'm actually apposed to the filename you used for the script you want me
to own.

I consider myself a low-volume email maintainer and I get enough useless
emails about apparent trivial fixes that end up causing significant
damage if they are not dealt with.  So I take care not to sign up for
more time erosion from meaningful forward progress on tasks I hope to
have high impact.  I suspect you know that, but I don't know you so I
don't want to assume.

Is there anything else you might want to share to entice me to maintain
this file?  Perhaps there's a documentation pointer that shows how
useful it is and why I should use it?

Right now, I have no idea what that file does or how to even check if
that file works today, so I cannot sign on to maintain it.

If you want to depend on APIs, this should probably be generated in a
way that enables updates.  And if that's the case, then why even have a
file at all and just generate it when needed?  Or, at least, half
generated and finished by hand?

Maybe this is the case but scripts/gdb doesn't have any documentation in
there, there's no Documentation/scripts or Documentation/gdb either.

Can you please include more details on the uses of these files?  Failing
that, perhaps you could point to any documentation?

...

Regards,
Liam

On 26.06.25 18:17, Liam R. Howlett wrote:
> * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>
>> These scripts are typically maintained in isolation from the subsystem
>> that they parse the data structures and symbols of, which can lead to
>> people playing catch up with fixing bugs or updating the script to work
>> with updates made to the internal APIs/objects etc. Here are some
>> recents examples:
>>
>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>
>> This patch series is intentionally split such that each subsystem
>> maintainer can decide whether to accept the extra
>> review/maintenance/guidance that can be offered when GDB scripts are
>> being updated or added.
> 
> I don't see why you think it was okay to propose this in the way you
> have gone about it.  Looking at the mailing list, you've been around for
> a while.
> 
> The file you are telling me about seems to be extremely new and I needed
> to pull akpm/mm-new to discover where it came from.. because you never
> Cc'ed me on the file you are asking me to own.
> 
> I'm actually apposed to the filename you used for the script you want me
> to own.
> 
> I consider myself a low-volume email maintainer and I get enough useless
> emails about apparent trivial fixes that end up causing significant
> damage if they are not dealt with.  So I take care not to sign up for
> more time erosion from meaningful forward progress on tasks I hope to
> have high impact.  I suspect you know that, but I don't know you so I
> don't want to assume.
> 
> Is there anything else you might want to share to entice me to maintain
> this file?  Perhaps there's a documentation pointer that shows how
> useful it is and why I should use it?
> 
> Right now, I have no idea what that file does or how to even check if
> that file works today, so I cannot sign on to maintain it.
> 
> If you want to depend on APIs, this should probably be generated in a
> way that enables updates.  And if that's the case, then why even have a
> file at all and just generate it when needed?  Or, at least, half
> generated and finished by hand?
> 
> Maybe this is the case but scripts/gdb doesn't have any documentation in
> there, there's no Documentation/scripts or Documentation/gdb either.
> 
> Can you please include more details on the uses of these files?  Failing
> that, perhaps you could point to any documentation?

FWIW, I once wrote
Documentation/process/debugging/gdb-kernel-debugging.rst. Hope it didn't
age too much.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

On 6/26/25 09:17, Liam R. Howlett wrote:
> * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>
>> These scripts are typically maintained in isolation from the subsystem
>> that they parse the data structures and symbols of, which can lead to
>> people playing catch up with fixing bugs or updating the script to work
>> with updates made to the internal APIs/objects etc. Here are some
>> recents examples:
>>
>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>
>> This patch series is intentionally split such that each subsystem
>> maintainer can decide whether to accept the extra
>> review/maintenance/guidance that can be offered when GDB scripts are
>> being updated or added.
> 
> I don't see why you think it was okay to propose this in the way you
> have gone about it.  Looking at the mailing list, you've been around for
> a while.

This should probably have been posted as RFC rather than PATCH, but as I 
indicate in the cover letter this is broken down to allow maintainers 
like yourself to accept/reject

> 
> The file you are telling me about seems to be extremely new and I needed
> to pull akpm/mm-new to discover where it came from.. because you never
> Cc'ed me on the file you are asking me to own.

Yes, that file is very new indeed, and my bad for not copying you on it.

I was not planning on burning an entire day worth of work to transition 
the GDB scripts dumping the interrupt tree away from a radix tree to a 
maple tree. All of which happens with the author of that conversion 
having absolutely no idea that broke anything in the tree because very 
few people know about the Python GDB scripts that Linux has. It is not 
pleasant to be playing catch when it would have take maybe an extra 
couple hours for someone intimately familiar with the maple tree to come 
up with a suitable implementation replacement for mtree_load().

So having done it felt like there is a maintenance void that needs to be 
filled, hence this patch set.

> 
> I'm actually apposed to the filename you used for the script you want me
> to own.

Is there a different filename that you would prefer?

> 
> I consider myself a low-volume email maintainer and I get enough useless
> emails about apparent trivial fixes that end up causing significant
> damage if they are not dealt with.  So I take care not to sign up for
> more time erosion from meaningful forward progress on tasks I hope to
> have high impact.  I suspect you know that, but I don't know you so I
> don't want to assume.

That seems entirely sane and thanks for being explicit about it.

> 
> Is there anything else you might want to share to entice me to maintain
> this file?  Perhaps there's a documentation pointer that shows how
> useful it is and why I should use it?

It can be as simple as spawning a QEMU instance:

qemu-system-x86_64 \
         -s \
         -cpu "max" \
         -smp 4 \
         -kernel ~/dev/linux/arch/x86/boot/bzImage \
         -device pci-bridge,id=pci_bridge1,bus=pci.0,chassis_nr=1 \
         -drive 
file=debian.img,if=none,id=drive-virtio-disk0,format=qcow2 -device 
virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
\
         -nographic \
         -append "root=/dev/vda1 console=ttyS0,115200 mitigations=off" \
         -net nic,model=e1000 -net tap,ifname=tap0

and in another terminal running GDB with:

gdb vmlinux -ex "target remote localhost:1234" -ex "lx-interruptlist"

to obtain a dump of /proc/interrupts which is effectively a replacement 
for iterating over every interrupt descriptor in the system.

> 
> Right now, I have no idea what that file does or how to even check if
> that file works today, so I cannot sign on to maintain it.
> 
> If you want to depend on APIs, this should probably be generated in a
> way that enables updates.  And if that's the case, then why even have a
> file at all and just generate it when needed?  Or, at least, half
> generated and finished by hand?

As it stands today that is not happening, there is zero coordination and 
people who care about GDB scripts just play catch up. But you raise a 
good point, if we are to do that, then we should be able to target 
C/Rust/Python/whatever, that seems like a bigger undertaking and I am 
not clear whether the kernel community as a whole is looking for 
transitioning over to something like this.

> 
> Maybe this is the case but scripts/gdb doesn't have any documentation in
> there, there's no Documentation/scripts or Documentation/gdb either.
> 
> Can you please include more details on the uses of these files?  Failing
> that, perhaps you could point to any documentation?

See the two commands above, those should give you a good environment to 
play with the various GDB scripts which are all prefix with "lx-".

Thanks!
-- 
Florian

On Thu 26-06-25 09:39:36, Florian Fainelli wrote:
> On 6/26/25 09:17, Liam R. Howlett wrote:
> > * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
> > > Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
> > > that provide OS awareness for debuggers and allows for debugging of a
> > > variety of data structures (lists, timers, radix tree, mapletree, etc.)
> > > as well as subsystems (clocks, devices, classes, busses, etc.).
> > > 
> > > These scripts are typically maintained in isolation from the subsystem
> > > that they parse the data structures and symbols of, which can lead to
> > > people playing catch up with fixing bugs or updating the script to work
> > > with updates made to the internal APIs/objects etc. Here are some
> > > recents examples:
> > > 
> > > https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
> > > https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
> > > https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
> > > 
> > > This patch series is intentionally split such that each subsystem
> > > maintainer can decide whether to accept the extra
> > > review/maintenance/guidance that can be offered when GDB scripts are
> > > being updated or added.
> > 
> > I don't see why you think it was okay to propose this in the way you
> > have gone about it.  Looking at the mailing list, you've been around for
> > a while.
> 
> This should probably have been posted as RFC rather than PATCH, but as I
> indicate in the cover letter this is broken down to allow maintainers like
> yourself to accept/reject
> 
> > 
> > The file you are telling me about seems to be extremely new and I needed
> > to pull akpm/mm-new to discover where it came from.. because you never
> > Cc'ed me on the file you are asking me to own.
> 
> Yes, that file is very new indeed, and my bad for not copying you on it.
> 
> I was not planning on burning an entire day worth of work to transition the
> GDB scripts dumping the interrupt tree away from a radix tree to a maple
> tree. All of which happens with the author of that conversion having
> absolutely no idea that broke anything in the tree because very few people
> know about the Python GDB scripts that Linux has. It is not pleasant to be
> playing catch when it would have take maybe an extra couple hours for
> someone intimately familiar with the maple tree to come up with a suitable
> implementation replacement for mtree_load().
> 
> So having done it felt like there is a maintenance void that needs to be
> filled, hence this patch set.

I can see that it takes a lot of time to do a major update of a gdb
debugging script after some refactoring like this. OTOH mandating some gdb
scripts update is adding non-trivial amount of work to changes that are
already hard enough to do as is. And the obvious question is what is the
value? I've personally never used these gdb scripts and never felt a strong
need for something like that. People have various debugging aids (like BPF
scripts, gdb scripts, there's crash tool and drgn, and many more) lying
around.  I'm personally of an opinion that it is not a responsibility of
the person doing refactoring to make life easier for them or even fixing
them and I don't think that the fact that some debug aid is under
scripts/gdb/ directory is making it more special. So at least as far as I'm
concerned (VFS, fsnotify and other filesystem related stuff) I don't plan
on requiring updates to gdb scripts from people doing changes or otherwise
actively maintain them.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

On 6/27/25 00:55, Jan Kara wrote:
> On Thu 26-06-25 09:39:36, Florian Fainelli wrote:
>> On 6/26/25 09:17, Liam R. Howlett wrote:
>>> * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
>>>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>>>> that provide OS awareness for debuggers and allows for debugging of a
>>>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>>>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>>>
>>>> These scripts are typically maintained in isolation from the subsystem
>>>> that they parse the data structures and symbols of, which can lead to
>>>> people playing catch up with fixing bugs or updating the script to work
>>>> with updates made to the internal APIs/objects etc. Here are some
>>>> recents examples:
>>>>
>>>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>>>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>>>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>>>
>>>> This patch series is intentionally split such that each subsystem
>>>> maintainer can decide whether to accept the extra
>>>> review/maintenance/guidance that can be offered when GDB scripts are
>>>> being updated or added.
>>>
>>> I don't see why you think it was okay to propose this in the way you
>>> have gone about it.  Looking at the mailing list, you've been around for
>>> a while.
>>
>> This should probably have been posted as RFC rather than PATCH, but as I
>> indicate in the cover letter this is broken down to allow maintainers like
>> yourself to accept/reject
>>
>>>
>>> The file you are telling me about seems to be extremely new and I needed
>>> to pull akpm/mm-new to discover where it came from.. because you never
>>> Cc'ed me on the file you are asking me to own.
>>
>> Yes, that file is very new indeed, and my bad for not copying you on it.
>>
>> I was not planning on burning an entire day worth of work to transition the
>> GDB scripts dumping the interrupt tree away from a radix tree to a maple
>> tree. All of which happens with the author of that conversion having
>> absolutely no idea that broke anything in the tree because very few people
>> know about the Python GDB scripts that Linux has. It is not pleasant to be
>> playing catch when it would have take maybe an extra couple hours for
>> someone intimately familiar with the maple tree to come up with a suitable
>> implementation replacement for mtree_load().
>>
>> So having done it felt like there is a maintenance void that needs to be
>> filled, hence this patch set.
> 
> I can see that it takes a lot of time to do a major update of a gdb
> debugging script after some refactoring like this. OTOH mandating some gdb
> scripts update is adding non-trivial amount of work to changes that are
> already hard enough to do as is. 

This really should have been posted as RFC, because I can see how 
posting this as PATCH would be seen as coercing maintainers into taking 
those GDB scripts under their umbrella.

> And the obvious question is what is the
> value? I've personally never used these gdb scripts and never felt a strong
> need for something like that. People have various debugging aids (like BPF
> scripts, gdb scripts, there's crash tool and drgn, and many more) lying
> around. 

Those are valuable tools in the tool box, but GDB scripts can work when 
your only debug tool accessible is JTAG for instance, I appreciate this 
is typically miles away from what most of the kernel community does, but 
this is quite typical and common in embedded systems. When you operate 
in that environment, having a decent amount of debugger awareness of 
what is being debugged is immensely valuable in saving time.

> I'm personally of an opinion that it is not a responsibility of
> the person doing refactoring to make life easier for them or even fixing
> them and I don't think that the fact that some debug aid is under
> scripts/gdb/ directory is making it more special. 

That is really the question that I am trying to get answered with this 
patch series. IMHO as a subsystem maintainer it is not fair to be 
completely oblivious to scripts that live in the source tree, even if 
you are not aware of those.

 > So at least as far as I'm> concerned (VFS, fsnotify and other 
filesystem related stuff) I don't plan
> on requiring updates to gdb scripts from people doing changes or otherwise
> actively maintain them.

vfs.py script is beyond trivial, the largest and most complicated IMHO 
is mapletree.py which had to be recently developed to continue to 
support parsing the interrupt descriptor tree in the kernel, I can 
maintain that one now that I know a lot more than I ever wished I knew 
about maple trees. So really the burden is not as big as it may seem but 
it's fair not to be taking on more work as a maintainer, I get that.

Thanks for your feedback!
-- 
Florian