lkml.org 
[lkml]   [2002]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.260 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site