linux-mips
[Top] [All Lists]

Re: [PATCH] dump_stack() based on prologue code analysis

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH] dump_stack() based on prologue code analysis
From: David Daney <ddaney@avtrex.com>
Date: Thu, 27 Jul 2006 09:54:58 -0700
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <20060726.232231.59465336.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060726.232231.59465336.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
Atsushi Nemoto wrote:
Instead of dump all possible address in the stack, unwind the stack
frame based on prologue code analysis, as like as get_chan() does.
While the code analysis might fail for some reason, there is a new
kernel option "raw_show_trace" to disable this feature.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>

Let me start by saying I have not analyzed how all this code works, but I have done something similar in user space.

Since the kernel ABI does not use gp, many functions may not have a prolog (especially when compiled with newer versions of GCC). In the user space case, most leaf functions have no prolog. For the kernel I would imagine that many non-leaf functions (simple non-leaf functions that do only a tail call) would also not have a prolog.

I would be worried that many stack traces would become less useful.

If this were conditional on -fno-omit-frame-pointer, then I think it would be a good idea.

David Daney.


<Prev in Thread] Current Thread [Next in Thread>