Description
When things go wrong, we need to debug the kernel. There are about as many ways to do that as you can imagine: printk, kdb/kgdb over serial, tracing, attaching debuggers to /proc/kcore, and post-mortem debugging using core dumps, just to name a few. Frequently, tools and approaches used by userspace debuggers aren't enough for the requirements of the kernel, so special tools are created to handle them: crash, drgn, makedumpfile, libkdumpfile, and many, many others.
drgn is currently read-only: it can attach to the running kernel and read memory, but it can't modify memory or modify the flow of execution. These read-write features would clearly be useful for development (for example, in a virtual machine or a lab). If done safely, they could also be useful for modifying the kernel in production. There are many potential...
Kernel debugging takes a variety of forms, but when a "real debugger" is required, you usually need to have debuginfo, and the standard kind of debuginfo is usually DWARF.
While DWARF is very powerful, it's not always the right choice for every situation. Fortunately, the kernel already contains nearly enough introspection information to power basic debugging operations. Kallsyms can...
For some lightweight systems, triggering a kdump could be a bit painful - it requires a generous amount of RAM to be pre-reserved, not available for regular usage at kernel runtime. Also, the panic kernel boot process takes time, and is prone to non-deterministic failures due to HW status or related to the cause of the panic event. So, despite kdump is a pretty standard way for collecting...
Qualcomm devices in engineering mode provide a mechanism for generating full system RAM dumps from field / test farm for postmortem debugging even in the case of not-kernel system crashes. But, on end user devices, taking complete RAM dump at the moment of failure has substantial storage requirement as well as it is time consuming to transfer them electronically. So, instead of copying and...