On 6/26/25 09:17, Liam R. Howlett wrote:
* Florian Fainelli <florian.faine...@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.ambar...@gmail.com/
https://lore.kernel.org/all/20250619225105.320729-1-florian.faine...@broadcom.com/
https://lore.kernel.org/all/20250625021020.1056930-1-florian.faine...@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
