linux-mips
[Top] [All Lists]

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

To: ths@networkno.de
Subject: Re: [PATCH] dump_stack() based on prologue code analysis
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Fri, 28 Jul 2006 23:38:42 +0900 (JST)
Cc: vagabon.xyz@gmail.com, ddaney@avtrex.com, linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <20060727191245.GD4505@networkno.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060727170305.GB4505@networkno.de> <cda58cb80607271151n2dcfe64cn4cb1ecca3ece6b1e@mail.gmail.com> <20060727191245.GD4505@networkno.de>
Sender: linux-mips-bounce@linux-mips.org
On Thu, 27 Jul 2006 20:12:45 +0100, Thiemo Seufer <ths@networkno.de> wrote:
> IOW, binary analysis can't be expected to provide full accuracy, but
> we can live with a reasonable approximation, I think.

Yes, this is a starting point.

The patch (and current mips get_wchan() implementation) tries to do is
what I used to do to analyze stack dump by hand.

1. Determine PC and SP.
2. Disassemble a function containing the PC address.
3. If the function is leaf, make use RA for new PC.
4. Otherwise, obtain saved RA from stack and use it for new PC.
5. Calculate new SP by undoing "addiu sp,sp,-imm".
6. Back to (2).

While it is hard to make the get_frame_info() perfect, this approach
might fail sometimes.  But it can work well for most case, and if it
did well we can get very good stack trace than current one (which may
contain so many false entries).

If you wanted to know the difference, please try ALT-SYSRQ-T (or
BREAK-T for serial console) with and without this patch :-)

---
Atsushi Nemoto

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