Messages in this thread | | | Date | 30 Mar 2002 12:06:00 +0200 | From | (Kai Henningsen) | Subject | Re: [PATCH] generic show_stack facility |
| |
davidm@napali.hpl.hp.com (David Mosberger) wrote on 29.03.02 in <15524.45472.231096.377756@napali.hpl.hp.com>:
> As far as I know, the x86 version of show_trace() still relies on the > fact that (a) return addresses are stored on the memory stack, (b) > they are stored in the order in which the routines were called, and > (c) that there aren't too many other values on the stack that look > like kernel text addresses. As long as an x86 compiler uses the CALL > instruction, that should be the case.
(b) is certainly not necessarily true for architectures like PPC, but the rest seems fairly unobjectionable - assuming that you first flush out your registers so any addresses only in registers get put on the stack, too. At least outside of Forth, separate return stacks seem to be extremely rare.
And as for the possibility of using several registers for return addresses such that dumping them leaves them on the stack out of order, well, the only thing I can see to get the original order back is to consult debug information that says where, on every call, to look for the next-up return address. Which doesn't seem quite feasible with anything less than a full gdb to do it.
What I don't see is what connection this can possibly have to the prototype of a stack dump routine.
MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |