Shudder. I had to do that for kdb and it is as ugly as sin. See
kdba_prologue and kdb_get_next_ar in the kdb patch, especially the
comments at the start of kdb_get_next_ar. ix86 back trace has special
cases galore. This is why an oops dumps so much rubbish in the "call
trace" on ix86, it is just too hard to get a correct call trace so we
print anything on stack that might be a kernel or module address and
expect the user to filter out all the false positives.
Also bear in mind that for running threads you have no idea where the
stack pointer is, esp is not saved in the process table unless the
thread blocks. So sysrq-T cannot even think about looking at the stack
for running threads on other cpus unless you force them to block first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/