kgdb kernel-backtrace for waiting process

2026-07-03

Stack Overflow: View Question

Tags: linux-kernel, task, x86-64, kgdb

Score: 0 | Views: 96

The asker is debugging a Linux system under KVM with kgdb. A userspace process is blocked inside folio_wait_bit_common() (page cache waiting for a folio bit — usually PG_locked or PG_writeback). They can see this in /proc/$pid/stack, but they need more than a symbolic backtrace: they want to inspect an argument passed to a function further up the saved call chain. Using the lx-ps gdb script, they've recovered a valid struct task_struct * (confirmed via task->comm). Now they need to reconstruct that task's kernel stack frames and locals from a stopped-in-kgdb state.

Why this is hard: The task isn't running — it's parked on a wait queue after __schedule() stashed its register state. On x86-64 there's no ABI-mandated frame pointer chain by default (kernels typically build with -fno-omit-frame-pointer only when CONFIG_FRAME_POINTER=y; ORC unwinding is the modern default). GDB's own unwinder can't unwind a task it doesn't have registers for. And even with unwind info, function arguments may live in registers that were clobbered before the call site of interest — DWARF location lists tell you where a variable lived at each PC, but only if the kernel was built with sufficient debug info (CONFIG_DEBUG_INFO=y, ideally CONFIG_DEBUG_INFO_DWARF5=y, and not stripped).

Approach:

Gotchas: ORC unwind tables live in the vmlinux but GDB doesn't consume them — it needs DWARF. Inlined functions (folio wait paths are heavy with inlines) collapse frames; you may need disassemble and manual decoding. If CONFIG_RANDOMIZE_BASE (KASLR) is on and you loaded symbols at the compile-time base, everything is offset — use lx-symbols after KASLR resolves, or boot with nokaslr for debug builds.

The challenge: Reconstructing a sleeping task's stack in kgdb means faking a register context from task_struct.thread.sp and hoping DWARF survived the optimizer — because ORC doesn't help GDB, and inlined wait paths eat the frames you actually want.

All newsletters