From: Omar Sandoval <osandov@osandov.com>
To: "Shenhar, Talel" <talel@amazon.com>
Cc: linux-debuggers@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Inquiring about Debugging Platform Drivers using Crash Utility for Kernel Coredump
Date: Tue, 20 Jun 2023 11:12:44 -0700 [thread overview]
Message-ID: <ZJHsHBQOWtvwZXlz@telecaster> (raw)
In-Reply-To: <f8f62216-ffaa-2f4e-ac5f-7dcd86e80a84@amazon.com>
On Tue, Jun 20, 2023 at 01:47:10PM +0300, Shenhar, Talel wrote:
> Dear Linux Kernel Community,
>
> I hope this message finds you well.
>
> I'd like to use crash utility for postmortem of my kernel coredump analysis.
>
> I was able to collect coredump and able to use various operation from within
> the crash utility such as irq -s, log, files and others.
>
> I am using: crash-arm64 version: 7.3.0, gdb version: 7.6, kernel version
> 4.19.
>
> My specific interest lies in debugging drivers internal state, e.g. platform
> drivers.
>
> For some hands-on experience with crash utility I'd like to start by
> iterating over all the platform drivers and print their names,
>
> However, I am finding it challenging to get started with this process and I
> am uncertain of the best approach to achieve this. I have scoured various
> resources for insights, but the information related to this specific usage
> seems to be scattered and not exhaustive.
>
> Given the collective expertise on this mailing list, I thought it would be
> the best place to seek guidance. Specifically, I would appreciate it if you
> could provide:
>
> Any relevant documentation, guides, or tutorials to debug platform drivers
> using the crash utility for kernel coredump analysis.
> Some simple examples of using the crash utility to debug platform drivers,
> if possible.
> Any important points or common pitfalls to keep in mind while performing
> this kind of analysis.
> Any other tips, best practices, or recommendations to effectively debug
> platform drivers using the crash utility would also be greatly appreciated.
>
> Thank you for your time and assistance. I look forward to hearing from you.
Hi, Talel,
The only thing I have to add to Stephen's excellent answer is my attempt
at getting the information you requested with drgn. I'm not very
familiar with platform drivers, so I basically read the code for
platform_driver_register() and translated the relevant parts to drgn.
Something like this should get you started:
------------------------------------------------------------------------
from drgn import NULL, container_of
from drgn.helpers.linux.list import list_for_each_entry
# This was directly translated from the bus_to_subsys() function in
# drivers/base/bus.c of the Linux kernel. We should probably add it as a
# drgn helper.
def bus_to_subsys(bus):
for sp in list_for_each_entry(
"struct subsys_private",
prog["bus_kset"].list.address_of_(),
"subsys.kobj.entry",
):
if sp.bus == bus:
return sp
return NULL(bus.prog_, "struct subsys_private *")
# Platform drivers are registered to the struct bus_type
# platform_bus_type in drivers/base/platform.c. The struct
# subsys_private has a kset containing a list of drivers.
sp = bus_to_subsys(prog["platform_bus_type"].address_of_())
for priv in list_for_each_entry(
"struct driver_private", sp.drivers_kset.list.address_of_(), "kobj.entry"
):
# This is a struct device_driver *.
driver = priv.driver
# To get the struct platform_driver *, do:
# platform_driver = container_of(driver, "struct platform_driver", "driver")
print(driver.name.string_().decode())
------------------------------------------------------------------------
(I also pushed this script to the contrib directory of the drgn
repository:
https://github.com/osandov/drgn/blob/main/contrib/platform_drivers.py)
On my ARM64 QEMU VM, this prints:
------------------------------------------------------------------------
sbsa-uart
alarmtimer
simple-pm-bus
pci-host-generic
of_fixed_factor_clk
of_fixed_clk
gpio-clk
------------------------------------------------------------------------
Hopefully this helps!
prev parent reply other threads:[~2023-06-20 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 10:47 Inquiring about Debugging Platform Drivers using Crash Utility for Kernel Coredump Shenhar, Talel
2023-06-20 16:41 ` Stephen Brennan
2023-06-20 18:12 ` Omar Sandoval [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZJHsHBQOWtvwZXlz@telecaster \
--to=osandov@osandov.com \
--cc=linux-debuggers@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=talel@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).